Professional Documents
Culture Documents
BMC Remedy Approval Server 70 Guide For Users and Administrators
BMC Remedy Approval Server 70 Guide For Users and Administrators
Copyright 1991-2006 BMC Software, Inc. All rights reserved. BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and all other BMC Software product or service names, are registered trademarks or trademarks of BMC Software, Inc. All other trademarks belong to their respective companies. BMC Software, Inc., considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable end user license agreement or nondisclosure agreement for the product and the proprietary and restricted rights notices included in this documentation. For license information about the OpenSource files used in the licensed program, please read OpenSourceLicenses.pdf. This file is in the \Doc folder of the distribution CD-ROM and in the documentation download portion of the product download page. Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.
Contacting Us If you need technical support for this product, contact Customer Support by email at support@remedy.com. If you have comments or suggestions about this documentation, contact Information Development by email at doc_feedback@bmc.com. This edition applies to version 7.0 of the licensed program.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Whats new in 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Related BMC Remedy documents . . . . . . . . . . . . . . . . . . . . 16 Learn more about the AR System Developer Community. . . . . . . . . . 17 Why should you participate in the Developer Community? . . . . . . . . 17 How do you access the Developer Community? . . . . . . . . . . . . . 17
Chapter 1
. . . . . . . . . . . . . . . . . . 19
Installation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 AR System server installation notes . . . . . . . . . . . . . . . . . . 20 Approval Web installation notes . . . . . . . . . . . . . . . . . . . 20 Licensing the Approval Server . . . . . . . . . . . . . . . . . . . . . 20 Installing the Approval Server on Windows. . . . . . . . . . . . . . . . 21 Installing the Approval Server on UNIX . . . . . . . . . . . . . . . . . 23 Using the Approval Server on the web . . . . . . . . . . . . . . . . . . 25 Manually starting and stopping the Approval Server . . . . . . . . . . . . 27 WindowsStarting the server . . . . . . . . . . . . . . . . . . . . 27 WindowsStopping the server . . . . . . . . . . . . . . . . . . . . 27 UNIXStarting and stopping the server manually . . . . . . . . . . . . 28 Using an AR System server without portmapper. . . . . . . . . . . . . . 30 Configuring the AR System server without portmapper . . . . . . . . . . 30 Configuring the Approval Server without portmapper . . . . . . . . . . 31
Contents
Uninstalling the Approval Server . . . . . . . . . . . . . . . . . . . . 31 Removing a Windows installation . . . . . . . . . . . . . . . . . . . 31 Removing a UNIX installation . . . . . . . . . . . . . . . . . . . . 31 Where to go next . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 2
Chapter 3
Chapter 4
Working as an approver
. . . . . . . . . . . . . . . . . . . . . 45
Processing an approval request . . . . . . . . . . . . . . . . . . . . . 46 Viewing approval requests . . . . . . . . . . . . . . . . . . . . . . . 46 Performing other approval actions . . . . . . . . . . . . . . . . . . . 47 Requesting more information. . . . . . . . . . . . . . . . . . . . . 48 Reassigning an approval request. . . . . . . . . . . . . . . . . . . . 48 Specifying the next approver . . . . . . . . . . . . . . . . . . . . . 48 Handling approval errors. . . . . . . . . . . . . . . . . . . . . . . . 49 Designating alternate approvers . . . . . . . . . . . . . . . . . . . . . 49 Designating alternate approvers for yourself. . . . . . . . . . . . . . . 49 Serving as an alternate approver. . . . . . . . . . . . . . . . . . . . 50 Managing alternate approver definitions . . . . . . . . . . . . . . . . 51 Performing overrides . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Contents
Chapter 5
Chapter 6
Chapter 7
Contents
Key features of the Approval Server . . . . . . . . . . . . . . . . . . . 85 Approval data . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Approval process . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Common rules and operations . . . . . . . . . . . . . . . . . . . . . 88 Self Check rulesPreventing unnecessary routing . . . . . . . . . . . . 90 Approver roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Next approver rulesDetermining who is next . . . . . . . . . . . . . 93 Approver responseSignature line . . . . . . . . . . . . . . . . . . 96 Statistical Decision-Making rulesDo you want to base your decision upon statistical data? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Routing completion checkWho is left? . . . . . . . . . . . . . . . 102 Process done rules . . . . . . . . . . . . . . . . . . . . . . . . 105 Summary of common process elements . . . . . . . . . . . . . . . 106 Approval process types . . . . . . . . . . . . . . . . . . . . . . . . . 107 Summary of process types . . . . . . . . . . . . . . . . . . . . . 114 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Chapter 8
Chapter 9
6 Contents
Chapter 10
Contents
Working with Get Authority Self rules . . . . . . . . . . . . . . . . . . 185 Defining get authority self rules . . . . . . . . . . . . . . . . . . . 185 Example of a Get Authority Self rule . . . . . . . . . . . . . . . . . 187 Working with Completion rules . . . . . . . . . . . . . . . . . . . . . 187 Defining Completion rules . . . . . . . . . . . . . . . . . . . . . 188 Example of a completion rule . . . . . . . . . . . . . . . . . . . . 188 Working with Signature Accumulator rules. . . . . . . . . . . . . . . . 189 Defining Signature Accumulator rules . . . . . . . . . . . . . . . . 190 Example of a Signature Accumulator rule. . . . . . . . . . . . . . . 191 Working with Statistical Override rules . . . . . . . . . . . . . . . . . 193 Defining Statistical Override rules . . . . . . . . . . . . . . . . . . 193 Example of a Statistical Override rule . . . . . . . . . . . . . . . . 195 Statistical Decision-Making approvals in a sample application . . . . . . . 196 Statistical decision making rules in the Get Agreement sample . . . . . . 199 Working with Approval Process Done rules . . . . . . . . . . . . . . . 201 Defining Approval Process Done rules . . . . . . . . . . . . . . . . 201 Example of an Approval Process Done rule . . . . . . . . . . . . . . 202 Working with existing rules. . . . . . . . . . . . . . . . . . . . . . . 203 Viewing rule stages . . . . . . . . . . . . . . . . . . . . . . . . 203 Modifying rules. . . . . . . . . . . . . . . . . . . . . . . . . . 205 Deleting rules . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Chapter 11
Chapter 12
8 Contents
Chaining approval processes . . . . . . . . . . . . . . . . . . . . . . 221 Using a status field in chained processes . . . . . . . . . . . . . . . 221 Flow between chained processes. . . . . . . . . . . . . . . . . . . 221 Restarting an approval process . . . . . . . . . . . . . . . . . . . . . 222 Special techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 More information. . . . . . . . . . . . . . . . . . . . . . . . . 223 Show summary and signatures . . . . . . . . . . . . . . . . . . . 224 Show password field if required . . . . . . . . . . . . . . . . . . . 225 Recommended technique: menu of valid names . . . . . . . . . . . . 225 Sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Sample user approval authority . . . . . . . . . . . . . . . . . . . 227
Chapter 13
Appendix A
Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Process worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Defining a process . . . . . . . . . . . . . . . . . . . . . . . . 242 More information escalations . . . . . . . . . . . . . . . . . . . . 242 Signature escalations . . . . . . . . . . . . . . . . . . . . . . . 243 Rule worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Auto-Approval rules . . . . . . . . . . . . . . . . . . . . . . . 245 Get Authority Self rules . . . . . . . . . . . . . . . . . . . . . . 246 Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . 246 Self-Approval rules . . . . . . . . . . . . . . . . . . . . . . . . 247 Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . 247 Prep Get Next Approver rules. . . . . . . . . . . . . . . . . . . . 248 Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . 249 Get Authority Regular rules . . . . . . . . . . . . . . . . . . . . 250 Completion rules . . . . . . . . . . . . . . . . . . . . . . . . . 250 Parameterized Get Next Approver rules . . . . . . . . . . . . . . . 251
Contents
Signature Accumulator Done rules . . . . . . . . . . . . . . . . . 252 Statistical Override Done rules . . . . . . . . . . . . . . . . . . . 252 Approval Process Done rules . . . . . . . . . . . . . . . . . . . . 253
Appendix B
Appendix C
10 Contents
AP:Process administrator . . . . . . . . . . . . . . . . . . . . . 293 AP:Process definition . . . . . . . . . . . . . . . . . . . . . . . 295 AP:Reserved word . . . . . . . . . . . . . . . . . . . . . . . . 301 AP:Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 AP:Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . 303 AP:Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 APW:Access Privileges . . . . . . . . . . . . . . . . . . . . . . . 310 APW:Approval Central . . . . . . . . . . . . . . . . . . . . . . 312 APW:More info requests . . . . . . . . . . . . . . . . . . . . . . 313 Business time holidays . . . . . . . . . . . . . . . . . . . . . . . 315 Business time workdays . . . . . . . . . . . . . . . . . . . . . . 315 User form xxx . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Appendix D
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . 319
Installation concerns. . . . . . . . . . . . . . . . . . . . . . . . . . 320 Previous Approval Server installations . . . . . . . . . . . . . . . . 320 Public group permissions . . . . . . . . . . . . . . . . . . . . . 320 Application pending form . . . . . . . . . . . . . . . . . . . . . 321 Errors not reported . . . . . . . . . . . . . . . . . . . . . . . . 322 Approval Web concerns . . . . . . . . . . . . . . . . . . . . . . . . 322 The Approval Central URL . . . . . . . . . . . . . . . . . . . . . 322 Sample application concerns . . . . . . . . . . . . . . . . . . . . . . 322 Sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Miscellaneous runtime concerns . . . . . . . . . . . . . . . . . . . . 323 Approver receives request but cannot respond. . . . . . . . . . . . . 323 Deadlocked approval server . . . . . . . . . . . . . . . . . . . . 323 Error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Appendix E
12 Contents
Preface
This chapter provides the following introductory information about the BMC Remedy Approval Server application: Audience (page 14) Whats new in 7.0? (page 15) Related BMC Remedy documents (page 16) Learn more about the AR System Developer Community (page 17)
Important: The compatibility information listed in the product documentation is subject to change. See the compatibility matrix at http://supportweb.remedy.com for the latest, most complete information about what is officially supported.
Carefully read the system requirements for your particular operating system, especially the necessary patch requirements.
Preface
13
Audience
This AR System 7.0 Approval Server guide is written for: Action Request System (AR System) users who want to understand approval workflow. Process Administrators who design and maintain approval processes. AR System Administrators who are responsible for installing and licensing the AR System Approval Server.
Note: The Approval Server Process Administrator is not the same as your AR System Administrator. See Chapter 7, Preparing process administrators, for a discussion of the Process Administrators responsibilities.
This guide assumes you are familiar with the BMC Remedy Action Request System. The administration sections assume you want to add the Approval Server to an existing application. This guide includes instructions for installing Windows and UNIX Approval Server forms and workflow, and assumes you are familiar with the environment in which you install the software.
Note: See Chapter 1, Installation and configuration, for instructions on how to install Approval Server 7.0.
14 Preface
15
Multitenancy supportThe 7.0 Approval Server supports multitenancy for use by application service providers. In the same AR System server, you can now include approval processes for applications that are shared by multiple companies. Field 112 with permissions to the Assignee Group only has been added to all Approval Server forms. The field 112 value from records created in the AP:Details form is used automatically in all the other Approval Server forms, for example, AP:Signature, AP:More Information, and so on. To use with application commands, see Add-Sig on page 258 and NewDetails on page 261. For information on access control in the AR System, see the BMC Remedy AR System Form and Application Objects guide.
Form and Application Objects Basic procedures for creating and guide modifying an AR System application for tracking data and processes. Workflow Objects guide Advanced procedures for extending and customizing AR System applications.
Administrators
Administrators
Unless otherwise noted, online documentation is available in Adobe Acrobat (PDF) format on AR System product installation CDs or on the Customer Support website.
16 Preface
17
18 Preface
Chapter
The AR System 7.0 Approval Server is available for Windows and UNIX (including Linux). Installation directions for both platforms appear in this chapter. The following topics are provided: Installation notes (page 20) Licensing the Approval Server (page 20) Installing the Approval Server on Windows (page 21) Installing the Approval Server on UNIX (page 23) Using the Approval Server on the web (page 25) Manually starting and stopping the Approval Server (page 27) Using an AR System server without portmapper (page 30) Uninstalling the Approval Server (page 31) Where to go next (page 32)
19
Installation notes
Updates to other AR System products (such as the BMC Remedy Change Management application) that are compatible with the 7.0 Approval Server release are being planned. Further information will be available as these updates become available. For the most current information about compatibility of various AR System products with the 7.0 Approval Server, see the Product Compatibility Matrix found at the following URL:
http://supportweb.remedy.com
You do not need to quit all applications before running the installer.
The CD Browser appears. If your computer is not set up to autorun CDROMs, then use Windows Explorer to view the root directory of the CDROM and double-click approval.exe.
2 Click Install Products.
A splash screen appears and the installer begins. After a short delay a welcome screen appears.
4 Click Next.
A dialog box appears asking you for the name of the AR System server where the Approval Server will be installed.
6 Enter the name of your server and, if needed, the number of the TCP port,
and then click Next. The installer starts the specified AR System server, if it is not already started. A dialog box then appears asking you for an AR System Administrator user name and password.
21
7 Enter this information into the appropriate fields and click Next.
A dialog box appears asking for additional localized views and data to install.
8 Select the localized views and data you want to install and click Next.
A dialog box appears asking if you want to install the Approval Server sample applications.
9 Click Next.
A dialog box appears asking for the destination path to install the BMC Remedy Approval Server.
10 Click Next to use the default or click Browse to select another directory.
You should use the default to install in the same directory as the AR System server.
11 Click Next to continue.
The installer might prompt you to change the permissions of the Public group from View to Change.
12 Click Yes to continue.
The installer continues installing the Approval Server software and imports workflow and data. When it is finished, the Import Completion dialog box appears.
13 Click OK.
The installer starts the service required for the Approval Server. The Log File Location dialog box appears, and the installation is complete. Log files are generated during the installation of this product. Upon successful completion, these files can be removed.
14 Click OK.
Usually you do not have to restart your machine to use the Approval Server. If a restart is necessary, a dialog box prompts you to do so. You can now log in to the AR System to start using the Approval Server, or continue to the next section to install Approval Web. See the end of this chapter for a road map for first-time process administrators.
For instructions on using the gunzip and tar utilities to uncompress and extract the contents of the approval_<UNIX_platform>.tar.gz file, see the Installing guide.
2 Change your current directory to the directory where you downloaded the
and provides a default server name based on the host name. Press Enter or type the proper server name and press Enter.
4 The installer script confirms the server name, asking
AR System Approval Server will be installed on <server_name>. Is this correct?
Press Enter if the directory is correct, or type N to return to the previous step.
5 The installer script asks
What is a valid AR System Administrator ID?
and provides a default if able. Press Enter to use the default, or type a valid Administrator ID and press Enter.
6 The installer script confirms the Administrator ID, asking
<ID> is the AR System Administrator ID to use. Is this OK?
Type the password for this Administrator ID you provided, and press Enter.
Installing the Approval Server on UNIX 23
Type the password for the Administrator ID you provided, and press Enter.
9 The installer script asks
What is the directory to install AR System Approval Server?
and provides a default directory. Press Enter or type the proper directory and press Enter. Without a specific reason, you should use the default values and install in the same directory as your AR System server.
10 The installer script then displays information about disk space requirements,
and verifies how much is available. If there is enough disk space, the installer asks
AR System Approval Server will be installed in the <directory_xxx>. Is this correct?
Press Enter if the directory is correct, or type N to return to the previous step.
Note: If there is not enough disk space available, the installer displays a message asking
Do you want to try to install in <directory _xxx> anyway?
Note: Press Enter or type Y to proceed. Type N to return to the previous step.
11 The installer script displays messages about the forms to install, and asks
Load AR System Approval Server forms into the AR System?
Press Enter to continue, or type N to proceed with the installation of only the Approval Server executable.
Note: If you do not install the Approval Server forms, the Approval Server cannot function. Answer No only if you are restoring the forms in another way.
The installer script displays many messages as it loads definitions of the Approval Server forms into the AR System. Loading might take several minutes to complete, so please be patient.
The installer starts the daemon for the Approval Server. The Approval Server is ready to use as soon as the installation is complete. Log files are generated during the installation of this product. Upon successful completion, these files can be removed. You can now log in to the AR System to start using the Approval Server, or continue to the next section to install Approval Web. See the end of this chapter for a road map for first-time process administrators.
To open the Approval Central application in your browser (as shown in Figure 1-1), enter the following URL:
http://<host_name>/arsys/apps/<server_name>/Approval Central
25
BMC Remedy Approval Server Figure 1-1: Approval Central displayed in browser
To view a list of all Approval Server forms in your browser, enter the following URL to open the AR System Object List:
http://<host_name>/arsys/forms
Your Approval Web and Administration components are ready for web users to access.
Note: For more information, see the Configuring and Form and Application Objects guides.
The first or only server installed on a computer is called Remedy Action Request System Server. Additional servers are listed as Action Request System <server name>.
3 Choose Action > Start.
27
The first or only server installed on a computer is named Remedy Action Request System Server. Additional servers are listed as Action Request System <server name>.
3 Choose Action > Stop.
AR System server.
Note: Make sure that you have read/write access to the /dev/console file before you restart the server as non-root.
2 Enter the appropriate command, as shown in the following UNIX start
commands table.
IBM AIX
Solaris
If you added a startup script, use /etc/init.d/arsystem start or, if you accepted the default installation directory, use /usr/ar/<server_name>/bin/arsystem start or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
start.
Linux
If you added a startup script, use /etc/init.d/arsystem start or, if you accepted the default installation directory, use /usr/ar/<server_name>/bin/arsystem start or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
start.
AR System server.
2 Enter the appropriate stop command: System Type HP-UX Command If you added a startup script, use /sbin/init.d/arsystem stop or, if you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
stop.
IBM AIX
If you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/ arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/ arsystem stop. If you added a startup script, use /etc/init.d/arsystem stop or, if you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/arsystem stop. If you added a startup script, use /etc/init.d/arsystem stop or, if you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/arsystem stop.
Solaris
Linux
29
server.
2 Choose File > Server Information > Server Ports and Multiple queues. 3 Enter a port number in the Server TCP/IP Port field.
(Windows) or
ar.conf
(UNIX).
Note: You must modify this file on each AR System server to be used without portmapper.
2 Add the following line to specify the port number.
Approval-Specific-Port: 9030
See Manually starting and stopping the Approval Server on page 27 for the procedures for Windows and UNIX.
31
Each uninstaller displays instructions at runtime. To proceed, you must enter a valid administrator login ID and password. You must also specify whether you want to uninstall shared forms.
Where to go next
See Chapter 2, Understanding the approval process, for basic Approval Server concepts. See Chapter 7, Preparing process administrators, for process administration concepts. See Chapter 5, Processing approval requests with Approval Central, for instructions on how to approve requests. See Chapter 6, Using a sample application, for a demonstration of acting as an approver using one of the sample applications. See Chapter 12, Implementing sample application features, for a demonstration of process administration using one of the sample applications. See Chapter 13, Adding approvals to your application, for instructions on how AR System administrators configure the Approval Server to work with existing applications.
Chapter
33
A given request might require one process for completion, or several processes that work with each other. Often the appearance of a single operation involves multiple approvals. One request can generate multiple approval processes Imagine an office employee requesting a faster personal computer. The request to purchase a new computer has to be approved by the employees manager. If the manager approves, a separate MIS department approval process then determines the model of computer to buy. These approval processes are separate, but both must be completed successfully for a computer to be delivered. Approval processes must be able to handle a variety of situations without failing. Imagine a process that skips required people, or gets routed to a person without authority, or a process that cannot cope with vacationing persons and other anomalies. When an approval process fails, so does the attached activity. The funds are not transferred, the apartment is leased to someone else, or the computer is never delivered.
35
When an AR System application triggers an approval process, the Approval Server routes a request to collect signatures within a defined approval process, handling all notifications and requests for more information as it collects each response (approving or rejecting). The Approval Server then reactivates the original application, reporting the result of the approval process. Finally, the Approval Server includes built-in contingency handling that makes sure approvals are completed quickly and properly within the system.
Flexibility
Todays diverse demands require the Approval Server to be flexible enough for any AR System application. There are often differences in how approvals should work between different applications within the same company. Who needs to sign this next? Do I have all of the signatures I need? How many is enough? What happens if there is an error? The Approval Server provides flexibility so you can easily define or modify how each approval process should work. You can quickly set up new processes and adapt existing processes as changes appear in your environment. Customization of the Approval Server does not require programming, for example, when changing approval cycles, models, or approvers.
37
Chapter
39
Complex processes
Sometimes a single operation actually involves multiple approval processes chained together, such as when a manager has to approve a new computer purchase, but MIS has to pick out a specific model of computer. Process administrators need to set up these chained processes carefully. Properly designed, a chained approval process is transparent to the approvers and people requesting approval, so that it appears as one smooth operation.
Requesters
Requesters are the people who want something to be approved. Requesters work within an application that starts an approval process. They enter requests within the application and at some stage their application request must be approved. Their requests are routed to all required approvers and the results returned without further action by the requesters. The Approval Server allows requesters two interactions besides initiating a request: Requesters can check on the status of their requests. An approver can ask for more information from the requester, who will have to respond with the information to allow the approval process to continue.
Approvers
Approvers are people with the authority to approve or reject a request in a given process. Once you approve a request, you never see it again, and have no chance to change your mind. The request is routed only to the remaining approvers. Likewise, once you reject a request, you cannot change your mind. No one else sees it; the routing stops and the request is closed. Valid approvers for each process are set up in the Approval Server, and they are used to form a specific Approver List for each request. Different requesters can have different approver lists for the same process. An approver list specifies the exact list of signatures required for a specific request. A signature can come from an individual, or it can come from a role containing multiple individuals. The Approval Server allows you the flexibility to work with any combination of individuals and roles to create an Approver List for a particular process. Individual approver versus role Franks company rules say he can get the signature of any manager to authorize reimbursement for office supplies. However, company rules say Frank must get his direct supervisor to authorize reimbursement for travel related expenses. Jack, Larry, and Samantha have the role of manager, so any of them can approve Franks office supplies. Jack is the individual who supervises Frank, so only Jack can authorize Franks travel expenses.
Key concepts of the Approval Server 41
Approvers interact with the Approval Server more than requesters. They need to review outstanding requests that are assigned to them and take action on those requests. Approver actions are performed using one central form, called Approver Central. The actions they can take include: Approving Rejecting Reassigning Holding Requesting and responding to More Information Requests Checking status Approvers have access to the details of the item being processed as well as to the history of the approval detail record itself. This history includes all approvers who have had the request, and the actions they took. Also, any comments that have been entered by other approvers are available for review. As an Approver, you can define alternates to act as you for any approval process in which you participate. This substitution occurs during a time period you must specify.
Alternate
Approvers are not always available. When vacations or business trips occur, someone needs to cover for the individual who is out. Approvers can define an alternate with exactly their own capability and authority within an approval process. Having an alternate is not the same thing as having a peer with authority to approve the same process as you. An alternate is someone who substitutes for you and acts with your authority and privileges for a duration of your choice. Approvers have the option to set up any number of alternates, and each alternate might be set up to substitute within one or more approval processes.
When approvers designate you as an alternate, the Approval Server gives you the option to see your own approvals, or to see this other persons approvals as his or her alternate. You are always logged in as yourself, but you must specify whether you are acting as yourself or as an alternate. Acting as an alternate Jack is a regular approver for technical reviews. Samantha designates Jack as her alternate for technical reviews. Brigid designates Jack as her alternate for legal reviews. After Jack logs in to the Approval Server, he must select whether he wants to act as Jack, to act as Samantha, or to act as Brigid. Although Jack can switch between three approver identities, Jack can act as only one identity at a time. Because Jack must specify one identity before he sees any approval requests, there is no possibility that Jack can sign Samanthas requests with Brigids authority, or his own. When Jack acts as Samantha, it is irrelevant that he also has authority within the technical review process when acting as himself. When Jack acts as Samantha, he sees only Samanthas technical review requests and approves or rejects them with Samanthas authority. Likewise, when Jack acts as Brigid, he has Brigids authority within the legal review process, and cannot act as Brigid for technical reviews.
Process administrator
To automate approval processes, one person or authority must define each process. The Process Administrator is the person with the ability to define processes for the Approval Server. A second ability of the Process Administrator is the override. Sometimes emergencies require someone to override the normal flow of a process. The third ability of the Process Administrator is to grant others limited authority, allowing specific individuals an ability to configure a process, to override a process, or both. The Process Administrator also has the ability to designate alternates for any approver. Process Administrator actions are performed using one central form, called AP:Administration.
43
Note: An Approval Server Process Administrator is not the same as your BMC Remedy Action Request System Administrator. See Chapter 7, Preparing process administrators, for an explanation of the Process Administrators responsibilities.
Acknowledging approvals
The Approval Server has three methods to allow AR System users who are not approvers to track, or interact with, an approval process.
Notification
For every stage of the approval process, AR System notifications can be defined to inform interested parties of the status of an approval request.
Audit trail
All activity within the system is recorded within the detail record. The AR System captures approver activity, the time an activity occurred, and what that activity was. This allows you to track the progress of the entry and see which activity was performed at each stage.
Where to go next
Now that you understand the basic concepts of the AR System Approval Server, you can review the following chapters covering approvers, installation, and process administrators. Chapter 1, Installation and configuration, contains installation instructions for AR System administrators. Chapter 4, Working as an approver through Chapter 6, Using a sample application, contain concepts, procedures, and examples for approvers. Chapter 7, Preparing process administrators, and later chapters contain information for Approval Server Process Administrators.
44 Chapter 3The BMC Remedy model for approvals
Chapter
Working as an approver
This chapter discusses the approval process as it pertains to approvers. The following topics are provided: Processing an approval request (page 46) Viewing approval requests (page 46) Performing other approval actions (page 47) Handling approval errors (page 49) Designating alternate approvers (page 49) Performing overrides (page 51) Chapter 5, Processing approval requests with Approval Central, covers procedures for acting on approvals.
Working as an approver
45
If the request appears to be in order, you can approve it. If you need more information, you can enter a question or comment for the Approval Server to route to the requester or other individual. If the request appears unacceptable, you can reject it. Rejection typically ends the process for this request.
Note: The exception to the rejection outcome is statistical rules, introduced with the 5.1 release. For more information, see Get authority on page 104.
If you feel that you are not the appropriate person to approve the request, you can reassign it. For procedural information, see Chapter 5, Processing approval requests with Approval Central.
Guide for Users and Administrators Figure 4-1: Approval Central in browser
You can also view the Detail-Signature record for requests that have you as an approver. This is useful if you need historical information about a completed request, or if you want to verify the status of a current approval request that you have already approved.
47
As an approver, you can use the More Information request to ask a question regarding the original request. The original request then pauses until you respond to it. Others can see that the request is paused in a More Information status. Your response to the original approval is independent from the More Information routing. You never have to wait for the More Information answer. However, if you do approve or reject the original approval request, the Approval Server immediately closes your outstanding More Information Requests. For procedural information, see Processing More Information Requests on page 62.
For example, you receive an approval request for a piece of equipment that will be shared with another workgroup, and you need a signature from that workgroup in addition to your own. You can specify the approver in the other workgroup to whom the request is routed after you act on it. For procedural information, see Specifying next approvers on page 60.
Note: Specifying the next approver is not the same as reassigning an approval request. The option to specify the next approver requires you to approve or reject the request first. Use the option to reassign a request if instead of you, you want someone else to approve or reject a request.
49
Typically, one alternate is chosen for all approval processes, but you can designate more than one alternate approver, and you can also specify specific approval processes for each alternate. You must specify both a time period and the processes for which the alternate can grant approvals. For example, you can designate one alternate for three days, and another for four. You can designate one alternate with approval authority for all processes, and another alternate with authority to process your vacation requests but not your purchase requisitions.
Note: If your alternate designates an alternate, authority to sign your approvals is not passed on. Only the specific person you designate can act as your alternate.
Violet is out of the office for a week and designates Larry as her alternate. Larry departs on a surprise business trip, and designates Jack as his alternate. Jack does not have signature authority for Violets requests. Jack cannot see Violets requests. For procedural information, see Designating alternate approvers on page 66.
Acting as an alternate
The Approval Server reinforces the separate identities Larry can assume, by asking him to choose for whom he is acting: as himself, or as an alternate. If Brigid designates Larry as alternate, when Larry acts as himself, he reviews only his own approval requests. When Larry acts as Brigids alternate, he reviews requests only within processes where she has designated Larry as alternate. Acting as Brigid, Larry responds to Brigids requests with her authority in that process, even if Larry normally has weaker or stronger signature authority. For information about processing approvals, see Processing an approval request on page 46. For specific procedural information about serving as an alternate, see Acting as an alternate approver on page 68.
For procedural information, see Managing alternate approver definitions on page 68.
Performing overrides
Overrides can be thought of as a special power to correct unexpected situations. An override is performed by a process administrator instead of the normally defined approver, to move a request forward when the normal approver is not responding. An override is useful for emergencies such as when an approver is absent or unable to respond, and no alternate approver is designated. The process administrator can override that signature line so the process can continue.
Performing overrides
51
An override closes one approver signature, similar to acting as an alternate approver for one signature line, allowing the approval request to move on within the regular process. An override rejection terminates the request just as if the normal approver had rejected it. An override approval moves the request forward just as if the normal approver had approved it. If there are more approvers, the request is routed to them.
Note: A process administrator can give out override-only administrator privileges to any user without granting other approval process administrator privileges.
Global overrides
An advanced global override closes all open signatures, stops routing the request, and terminates the approval process for that request. This global override is useful for emergencies, such as ending an approval process for a request that is no longer necessary. Example of global override Imagine Sue makes a time-sensitive request that requires the approval of Samantha and Ned, in that order. Samantha is delayed by traffic and will not arrive in time to approve the request before it is required, therefore the sympathetic process administrator performs an override, immediately approving the request, which routes the request to Neds desk. Should it happen that Samantha and Ned are both delayed in traffic, the process administrator can perform a global override, approving or rejecting the request for all approvers at once, so Sue can react before her time limit expires. For procedural information about overrides, see Additional options for process administrators on page 70.
Chapter
53
Approval Server. See your AR System Administrator for the exact Approval Central URL of your Approval Server. For example, with a web server named acme that is accessing an AR System server named apex, the Approval Server URL might appear as follows:
http://acme/arsys/apps/apex/ApprovalCentral
In this example, Approval Central displays a table for each application on your Approval Server that lists your pending approval requests within that application. The applications displayed here are AP-Sample2:Get Agreement and AP-Sample:Lunch Scheduler. To add additional applications, see Connecting an application to the Approval Server on page 230.
3 From the applications displayed, click the request for which you are
processing an approval.
4 For each request, select the appropriate response from the menu list:
Approve, Reject, or No Action. You can also enter the name of the Next Approver, if appropriate.
5 In the Next Approver field, enter the name of the next approver.
55
WARNING: There is no undo option when you respond to a request. Once you respond to a request, you do not have any opportunity to change your mind.
7 Click a link in the navigation pane to access additional information.
Access Privileges lets you both specify alternate approvers for yourself and log in as an alternate approver for someone else. More Info Requests lets you view and modify More Information Requests you created and More Information Requests others have sent you. Help opens a new browser window to display context-sensitive online help. The Logout button logs you out of the Approval Server.
Guide for Users and Administrators Figure 5-2: Approval CentralRemedy User
In this example, Approval Central displays a table for each application on your Approval Server that lists your pending approval requests within that application. The applications displayed here are AP-Sample2:Get Agreement and AP-Sample:Lunch Scheduler. To add additional applications, see Connecting an application to the Approval Server on page 230.
4 From the applications displayed, click the request for which you are
processing an approval. When you click the Approve/Reject cell of a request, an arrow appears. This indicates a menu list you can use to process the approval request by choosing one of the following options: Approve Reject No Action For example, to approve the Get Agreement request displayed in Figure 5-2, select Approve.
5 For each request, select the appropriate response from the menu list.
57
6 Click the Next Approver cell to enter the name of the next approver.
Access Privileges lets you both specify alternate approvers for yourself and log in as an alternate approver for someone else. You can also create an alternate for yourself. More Info Requests lets you view and modify More Information Requests you created and More Information Requests others have sent you.
9 Choose Help > Help on Approval Central Application (or press F1) to open
To approve requests
1 Log in to the Approval Server as shown in Logging in to Approval Central
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Double-click the Req. ID column entry for the request you want to examine.
For example, in Figure 5-1 on page 55 you would click the number 0001 for the Get Agreement request. The Approval Detail view appears. You can now review the details of the request.
Figure 5-3: Reviewing the details of an approval request
3 From the Approval Status menu list, choose the status to which you want to
59
If you do not want to respond with approval or rejection, you can ask for more information, as described in Processing More Information Requests on page 62.
4 Add comments to the Comments field, if necessary. 5 Click Save Changes.
approval.
2 In the Next Approver field, enter the names of the next approvers.
This must be one or more exact AR System login IDs. To specify multiple approvers, separate each name with a semicolon (;).
3 Click Submit to save your changes.
Or:
1 Open the Details of the approval request as shown in Approving approval
This must be one or more exact AR System login IDs. To specify multiple approvers, separate each name with a semicolon (;).
3 Click Save Changes to save your changes.
option for the If Multiple Approvers field: To allow the request to be approved by a single signature, select One Must Sign. To require all specified approvers to sign for the request to be approved, select All Must Sign. Otherwise, use None, the default process setting for multiple approvers.
3 Click Save Changes to save your changes.
to reassign the request. This must be one persons exact AR System login ID.
3 Click Save Changes to save your changes.
61
3 In the To field, enter the name of the person from whom you want more
information. This can be the original requester or any other person, but it must be one persons exact AR System login ID.
4 In the Request field, enter your question or a description of the information
you need.
5 Click Submit to save your More Information request.
The following now occurs: The Approval Status for the approval request automatically changes to reflect your request for more information, and the Approval Server routes your request to the person in the To field. The More Information Requests appears in the Approval Detail window.
Figure 5-5: More Information Requests displayed
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click More Info Requests in the navigation pane.
The More Information Requests window appears. The top table lists the More Information Requests to you.
63
BMC Remedy Approval Server Figure 5-6: Displaying More Information Requests
3 Double-click the More Info ID for the request you want to respond to.
4 Type your answer in the Response field. 5 Click Submit to save your changes.
The status of the request will automatically change to Completed. The request no longer appears in More Information Requests window but the Approval Server routes your response back to the More Information requester.
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click More Info Requests in the navigation pane.
The More Information Requests window appears, as shown in Figure 5-6 on page 64. The bottom table lists the More Information Requests from you.
3 Double-click the More Info ID of any request for which you want to view
65
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click Access Privileges in the navigation pane.
4 In the Alternate field, type the AR System login name for the person to
alternate to have your signature authority. To authorize all processes for which you have signature authority, select All. To authorize a specific process, select Specific Process, and then select a process from the Process menu list.
7 Select No from the Notify Alternate menu if you want to prevent
notifications from being sent to the alternate for each new approval.
8 Click Submit to save your changes. 9 The Alternate Approvers table is refreshed with the new entry.
67
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click Access Privileges in the navigation pane.
The Access Privileges form appears, including the Change Current Approver section.
Figure 5-10: Entering an alternate login ID to act as Enter AR System Logon ID of the person for whom you are alternating.
3 From the I would like to approve request: menu list, select For Someone Else. 4 In the (Enter Login Name) field, type the AR System login name of the
The Approval Central screen appears. You can now approve requests with the signature authority of the person who designated you as alternate.
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click Access Privileges in the navigation pane.
The Access Privileges form appears, including the list of active alternate approvers.
Figure 5-11: Reviewing your designated alternates
69
If you want to cancel this approver, select Cancelled from the Status field.
4 Click Submit to save your changes.
procedure.
2 In the For field, type the AR System user ID of the person this alternate will
be substituting for.
3 Click Save to save your changes.
Performing overrides
If you have override capability for an approval process, you perform the same steps to approve or reject the request as the original approver; however, you must specify that you are performing an override. For conceptual information about overrides, see Performing overrides on page 51.
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click Access Privileges in the navigation pane.
The Access Privileges form appears, including the Change Current Approver section.
Figure 5-13: Selecting the override option
Enter AR System Logon ID of the person for whom you are alternating.
3 From the I would like to approve request: menu list, select As Override. 4 In the Login Name field, enter the name of the approver whose signature
The Approval Central screen appears with a list of the persons pending process records. You can now approve or reject their requests with override authority by performing one of the following tasks: Approve or reject the request from Approval Central. Open the request in the Approval Detail window if you need to add additional details.
71
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Click Access Privileges in the navigation pane.
The Access Privileges form appears, including the Change Current Approver section.
Figure 5-14: Selecting the global override option
3 From the I would like to approve request: menu list, select As Global
Override.
4 Click Change Approver to see requests as the global override approver.
The Approval Central screen appears with a list of all pending process records. With global override authority, you can now approve or reject their requests with override authority by performing one of the following tasks: Approve or reject the request from Approval Central. Open the request in the Approval Detail window if you need to add additional details.
Chapter
This chapter demonstrates how to use Get Agreement, one of the sample applications bundled with the Approval Server. The following topics are provided: Using the Get Agreement sample application (page 74) Summary of sample (page 82)
73
For more information, see the following methods: Logging in to Approval Central with a browser on page 54. Logging in to Approval Central with BMC Remedy User on page 56
2 Open the Get Agreement form in New mode.
Guide for Users and Administrators Figure 6-1: New request within Sample2:GetAgreement
3 Type I need a new computer in the Summary field. 4 Type a longer description in the Details field. Exact wording of the Details
Since this is an Ad Hoc process, every approver must be chosen manually. Use Jack Miller, Larry Goldstein, and Violet Anderson. Type a semicolon between each approvers name.
6 Click Save to save your request for a new computer.
Approving a request
The next procedure demonstrates how an approver responds to a request. It requires that you have completed the previous procedure, Making a new approval request.
1 Log in to the Approval Server as sample user Jack Miller using one of the
methods described in Processing approval requests with Approval Central on page 53.
75
Approval Central appears. Although most of the examples in this chapter use the web client, you could also use BMC Remedy User when processing approvals in Approval Central.
Figure 6-2: Approval Central application
2 Select the I need a new computer request from the Get Agreement
approvals.
3 Select Approve from the Approve/Reject cell in the Get Agreement
approvals, as shown in Figure 6-2. When you click the Approve/Reject cell of a request, a menu list appears for selecting approval options.
Note: If you see a warning saying you do not have permission to write to certain fields, this means Jack Miller is not a properly licensed AR System user. To continue with this example, your AR System administrator must license the sample users.
Notice that Franks request no longer appears in the list of Get Agreement approvals for Jack Miller. The next procedure requires that you followed the previous procedures regarding Frank Williams computer request.
methods described in Processing approval requests with Approval Central on page 53.
2 In Approval Central, open the I need a new computer request.
You can assign a More Information request to any valid AR System login name, including the requester. For this example, you are asking for more information from another approver.
77
5 Type a question in the Question field. The exact words are not critical for this
example.
6 Click Submit to create the More Information request.
The new More Information Request you created for Violet Anderson now appears in the Approval Detail window.
7 Click Save Changes in the Approval Detail window to save your changes.
In the requests from Larry Goldstein, the More Info Status field of this request displays Pending.
Note: Larry could approve or reject the approval request without waiting for Violets response to the More Information request. In this event, Larrys More Information request will be closed when Franks computer request is done, regardless of whether the More Information request was seen by Violet.
The More Information Requests window opens, displaying More Information Requests to Violet and from Violet.
4 Open the Pending item from Larry Goldstein.
The More Information dialog box appears with the Response field enabled.
Guide for Users and Administrators Figure 6-4: Responding to a more information request
5 Enter a response to the More Information request into the Response field.
The dialog box closes. The More Information Request is no longer visible to Violet after she responds to it.
Franks request is no longer available in Approval Central for Violet to approve or reject. Only Sue Smith and Larry can see Franks request now.
79
The More Information Requests window appears. It displays information requests for you to answer and information requests from you to other users.
Figure 6-5: Larrys completed more information request
The Modify More Info Request dialog box appears. With Violets response, Larry now has sufficient information to approve Franks request.
4 Cancel the Modify More Info Request dialog box.
5 Click Approval Central in the navigation pane. 6 In Approval Central, approve the I need a new computer request.
You can also open the request I need a new computer in the Approval Detail window, select Approved from the Approval Status menu list, and then click Save Changes to make your change permanent. Jack and Larry have approved, Violet has reassigned the request, so now only Sue Smith remains to approve or reject Franks computer request.
81
BMC Remedy Approval Server Figure 6-6: Status field displays approved
Summary of sample
The procedures in this chapter demonstrated how to respond to an approval request, as well as how to create and respond to a More Information request. You also learned how to reassign a request to another person when that option is available. If you want to explore the new statistical rules that were introduced in the 5.1 release, go to Statistical Decision-Making approvals in a sample application on page 196. There you will continue using the Get Agreement application to see how statistical decision-making rules operate.
Chapter
83
Approval data
The most important data generated by an approval request consists of the signatures of every person who approves or rejects the request. Other data useful for an audit trail includes More Information Requests and specific dates and times for each activity. The Approval Server collects this information about a Detail record for each request.
Detail record
All data about the approval are held in the Detail record. The Approval Server stores data about who authorized or rejected a request using the AP:Detail form. You can use this form to determine the status of a request, and see a history of activity on the request for a given approval process. The AP:Detail form captures and displays the essential data of every authorization and rejection generated by an approval process.
85
Supporting records
A number of supporting forms store and display information regarding each approval request. AP:Signature stores and displays the data regarding the signatures collected in the approval process. AP:More Information stores and displays the response should an approver ask for additional information before approving or rejecting a request. Join forms display information about your application and the approval forms. See the Connecting an application to the Approval Server on page 230 for more information about these join forms.
Approval process
When a group of employees needs to sign off on somethinga birthday card for another employee, for exampleyou must make sure every appropriate employee has a chance to sign the card, and that the card is delivered afterwards. Workers route approvals such as this birthday card without conscious thought to the rules for routing it. Yet there are rules in place. Usually it does not matter in what order people sign the card, but it would be inappropriate to request a second signature from someone who has already signed. Additionally, no one is usually required to sign a birthday card. And finally, it is inappropriate to request a signature from the person with the birthday! Processes abide by rules such as these without anyone thinking of them as rules. However, the Process Administrator setting up a business process must determine and implement all the rules.
87
Requester
Another Approver
Requester
1
Self Check Requester approved
2
Yes
Next Approver
Approver Response
3
Approval Cycle
More approvers?
5
Process Done
No
4
Completion Check Approved Rejected
determine whether the requester has sufficient authority to approve his or her own request. If so, the approval process is done and the approved workflow is returned to the requester.
Step 2 If the requester does not have enough authority to approve the request, the
Approval Server checks rules to find Next Approver. Next approver rules start a cycle of locating people who need to approve this request.
Step 3 If an approver rejects the request, the approval process is typically done and
enough people with sufficient authority have signed to Complete the authorization.
Step 5 When the approval process is Done, the Approval Server determines if the
Sue has a purchase order that has to be approved by two committee members, Samantha and Ned, in no particular order. Sue makes two photocopies and puts one in each of the approvers mailboxes. The approval process is complete at this point. No more routing actions need to occur. All approvers have received Sues request. However, Sues request is still active. Until Samantha and Ned have responded, the approval process for Sues purchase order is not done.
89
The Approval Server uses rules to determine the exact sequence of events to process an approval request. As Process Administrator, you should have some background on the types of rules available before you attempt to create your own approval processes.
Requester
1
Auto-Approval? Yes
No
Get authority
Next Approver
Approval Cycle
Selfapproval?
No
Process Done
Yes
If a rule says everyone in your company can be reimbursed for a business lunch up to $40, and Frank requests approval for a $25 lunch, this scenario would trigger an auto approval condition. Since it does not matter who is asking as long as the amount is less than $40, this companys auto approval rule automatically approves Franks request for his $25 lunch. When auto approval occurs, the request is done, and routed back to the requester.
The information collected by your Get Authority rules is used by Self Approval rules in the next operation of the Self Check.
91
Approver roles
If the Self Check cannot approve a request, then the request is routed to an approver with more authority than the requester. Authority for this approver can be established by a relationship with the requester, or by a role within your company. Consider the authority behind individuals in your organization. Generally authority is based on the persons relationship with the requester, or based on the role that this approver has within the organization. A relationship could be direct supervisor. A role could be marketing managers or company director. Think of a role as membership in a group, or a characteristic shared among many individuals. Role versus relationship Imagine your company allows any manager to approve a business lunch for up to $100. As Process Administrator, you would set up a manager role within the Approval Server and attach the names of all your managers to that role. Then when Frank requests approval for a $75 lunch, the request can be approved by any individual assigned to the manager role. Franks actual manager Jack can approve the request, or any of Jacks peers can do so, as long as they have the role of manager assigned within the Approval Server.
Alternately, if your company requires a lunch request above $100 to be approved by only the individual who supervises the requester, you can set up the process so only Jack, Franks direct supervisor, is allowed to approve Franks $150 request. In this case, the individual Jack has a specific relationship with Frank, and this relationship is set up within the Approval Server. The relationships and roles held by individuals determine the valid Approver List for any given process. With a valid Approver List, you can set up rules to find them. These rules, called Get Next Approver rules, are discussed in the next section.
93
Validate approver
The Approval Server uses validate approver rules to protect against inappropriate Ad Hoc assignments. These rules allow testing of Ad Hoc approvers to make sure they are authorized within this process. If the test fails, then the user assigning this approver receives an error, and must correct it before the request can proceed. Next Approver rules are presented in the following diagram.
Guide for Users and Administrators Figure 7-3: Get next approver rules
Ad hoc? No Yes
Validate Approver?
Approved Yes
Approver Response
More approvers?
Approved
Approval Cycle
To summarize, Next Approver Rules determine the next approver or set of approvers for the request and create appropriate signature lines for them. The request is then prepared for the next approvers to respond.
Note: As Process Administrator, you should set up notifications to indicate when a request is waiting for an approver, and when an erroneous Ad Hoc selection is waiting for correction.
95
Hold
When an approver places a request on hold, the Approval Server identifies the approval request with a Hold status, but no other action occurs within the approval processing. Process Administrators should establish escalations to prevent requests in Hold status from being neglected indefinitely.
The Approval Server allows an approver to hold, approve, or reject a request without waiting for the More Information response. When this occurs, the More Information request is terminated.
Reject
If the approver rejects a request, the request moves to the Process Done stage, as described in Process done rules on page 105, unless you have created statistically-driven rules. No more routing occurs, and it is withdrawn from approvers who have it on hold or requested More Information. For more information, see Get authority on page 104.
96 Chapter 7Preparing process administrators
Approve
When an approver approves a request, the Approval Server processes the request against the Routing Completion Check, discussed in the next section.
Statistical Decision-Making rulesDo you want to base your decision upon statistical data?
The default behavior of the Approval Server if you do not define any statistical override rules is that one rejected signature by an approver rejects the entire approval process and the process at that point is considered Done. But now you can specify two new rules to change this default behavior to support the following scenarios: Signature Accumulator rules help you collect information about the number of signature records that meet certain criteria that you define. For example, you can simply count the number of approved and rejected signatures. As you count, you can apply weightings or dollar amounts to each signature. After you have collected the information you need, you can use Statistical Override rules to approve or reject the request based on a ratio, or if the signatures have accumulated sufficient support or dollar amounts to warrant an approval or rejection. Weights and signature accumulator rules Imagine a large expense of $10,000 that cannot by approved or rejected by a single individual like Jack, but rather requires the accumulated weight of the signature authority of multiple individuals. If you were applying a weighting to signatures, you would actually use the Signature Accumulator rule as this rule is what collects information about the signatures. Information such as weighting would also be a part of the data-gathering role of the Signature Accumulator rule. The Statistical Override rule is more of a decision-making rule that bases the decision on the data collected by the Signature Accumulator rule.
97
These rules provide additional functionality to the Approval Server, but do not affect any existing functionality. These statistical rules start when the server receives an approval reject or cancel signal. If any Statistical Override rules are defined, then the statistical decision-making approval process begins. However, if no rules implement the Statistical Override rules, the server behavior reverts to its default logic, for example, one rejection and the process is Done. The entire statistical decision-making process is summarized next:
Figure 7-5: Statistical Decision-Making
No
Default Logic
Statistical Rules
Preempt?
No
More Signatures?
Yes
Error
Reject
No
Approve?
Yes
Default Logic
99
For each signature record, each Signature Accumulator rule is applied, provided the Run If qualification passes. The Run If condition is qualified on each signature, for example:
$Approval Status$ = Approved
If the Run If condition is met, the server will perform the Set Fields operation. The rules are applied according the order of the rule (ascending). The Set Fields operation is used to set up the data. Typically the Set Fields operation in a Signature Accumulator performs an addition to accumulate information, as in the following example:
$Temp Decimal 1$ = $Temp Decimal 1$ + $Signature Dollar Limit$
The assignment of the Set Fields operation is always to the application-detail record that the Approval Server is processing. After all rules have been applied for the given signature, the Approval Server moves to the next signature and applies the rules accordingly. You can also use the Set Fields operation also to look up information from another form and pull values into the calculation. This might be applicable should you want to apply a weight to a particular approver. For example, a list of signatures might include one individual who has ultimate authority along with additional approvers who carry the same weight, when combined, as the one individual. You do not need to count the number of signature records in any given state. the Approval Server counts the number of signature records in Pending, Approved, Rejected, Hold, More Information, Cancelled, Error, and Closed states. These values are available for you to use with the Signature Accumulator and Statistical Override rules and are stored in the following hidden fields in the AP:Detail join form: Total Pending Total Approved Total Rejected Total Hold Total More Information Total Cancelled Total Error Total Closed
As a result, if you create an Statistical Override rule, you do not have to create a temporary field to store the value of the number of signatures. The totals are created and stored in the fields listed. For information about creating Signature Accumulator rules, see Working with Signature Accumulator rules on page 189.
The Set Fields function then sets the result into the Statistical Override Field. The only valid Statistical Override values are either Approved or Rejected. When the Statistical Override rule approves or rejects the approval, the approval process is preempted by performing these actions:
Process type Level Signatures considered Only open signatures for the current level. All the signatures are considered at all times. All the signatures are considered at all times. All the signatures are considered at all times. Approving requests Preempts the Approval Server to proceed to the next level. Preempts the Approval Server to proceed to proceed to next parent. Preempts the Approval Server to approve the request. Preempts the Approval Server to proceed to the next set of approvers. Rejecting requests Preempts the Approval Server to reject the request and stop the processing. Preempts the Approval Server to reject the request and stop the processing. Preempts the Approval Server to reject the request and stop the processing. Preempts the Approval Server to reject the request and stop the processing.
Parent-Child
Ad Hoc
Rule-Based
101
If there are no Statistical Override rules defined for a process, then the default logic applies and Get Next Approver handling begins. This is very different from the situation where there are override rules defined, but they did not preempt the process.
Note: Each Statistical Override rule can perform one of three actions: Approve, Reject, or do nothing. If you Approve or Reject in an override rule, no further Statistical Override rules are considered. Processing of the override rules stops in the Approval Server at this point.
There also might be additional processing in the Approval Server if there are next approvers. If there are, new signature records might be generated. In most process types, this process is not marking the Detail portion of the approval process as being approved or rejected. Rather, this affects the way that the Approval Server processes the signature record and any other active signature records. It is only with a level-based process that you see the behavior where the detail record is not what is going to be updated immediately. For example, preempting other signatures with an approval decision in a level-based approval process will approve the request for the current level only; the Approval Server then seeks out further levels if they exist.
WARNING: If you define Statistical Override rules, you must define one rule to approve or reject the process if no pending signatures exist. If there are no more signatures to process, then the rules must either arrive at an Approve or Reject decision. If a rule is not defined to handle this condition, the Approval Server will consider this an error condition.
For information about creating Statistical Override rules, see Working with Statistical Override rules on page 193.
When Jack approves a business expense for $100, a Completion Check determines whether Jack has sufficient authority for that amount, for $100. If Jack can authorize that amount, the process passes the Completion Check. If Jack does not have such authority, then the Completion Check fails, and the routing of this request continues to another approver. Routing Completion check rules are shown in the following diagram.
Figure 7-6: Details of completion check rules
Submit Request
Next Approver
Approver Response
More approvers? No
Signature Accumulator
Approval Cycle
Rejected Statistical Override? Completion Approved
Process Done
It is important to construct your processes such that the Approval Server does not run out of approvers before the Completion Check has routed the request to a person with sufficient authority. For example, if you have a process to handle expenses up to $1000, it is important that the Approver List includes an individual or role with sufficient authority to sign for that amount. Otherwise your process will generate an error when it runs out of approvers without finding someone who can authorize a $1000 expense.
103
However, some processes are designed to run out of approvers. A process that requires a fixed number of signatures will complete successfully when the process exhausts the Approver List. For example, you can create a process that completes routing when any five approvers respond, instead of completing with one approver of a specific authority.
Get authority
The Completion Check has Get Authority rules to collect information as discussed in Self Check rulesPreventing unnecessary routing on page 90.
Previously, authorizing a business lunch required a person with authority to approve a dollar amount. When Franks $150 lunch request arrives at Jacks desk, if Jack has authority for $150 then the process is complete. If Jack has authority for a lesser dollar amount, then the approval process does not pass the Completion Check until someone approves with authority for at least $150. This Get Authority rule tests completion against a specific condition of a dollar amount. Imagine a different process that ignores dollar amounts, and instead requires the sign off from two steps up the chain of command, so Frank needs both his manager Jack, plus Jacks manager Larry to approve Franks business lunch request. When Frank gets his two signatures, no more approvers are required, so the process is complete.
Chained processes
By chaining processes, you can initiate a new approval process automatically when the first is done. For example, if a manager approves a new computer purchase, the MIS department can start another chained approval process that determines the exact model of computer to buy.
Note: Process Administrators should make sure a chained process starts only when the first process returns an appropriate result.
105
Guide for Users and Administrators Figure 7-7: Common process elements
2
Prep. Get Next Approver
Ad hoc? No Yes
Invalid Requester
Validate Approver?
1
Auto-Approval?
Approver Response No Get authority Yes Yes Get authority self Signature Accumulator No More approvers? (Wait for) Correction
Approval Cycle
Selfapproval? Statistical Override No No Yes
Rejected
5
Process Done
Yes
Yes
4
No Completion
The next section shows how the Approval Server assembles these concepts into four process types, useful for various business practices.
107
As you set up an approval process, you need a routing methodology that models your specific organization or processes. The situations in your organization are not all identical, and one process cannot cover all circumstances. Therefore the Approval Server offers three generic process types to model most circumstances, and a fourth process type lets you create custom rules for modeling scenarios outside the generic process types. The process type defines the model used to determine who gets the request after each person approves it. The four process types are Parent-Child, Level, Ad Hoc, and Rule-Based.
Guide for Users and Administrators Figure 7-8: Parallel Parent-Child hierarchies
The important factor to notice is the hierarchical relationship between approvers. The Parent-Child process makes sure that persons X will never see this approval request. Persons X do not have parent relationships with anyone on the departmental hierarchies. This approval process consists of two Parent-Child hierarchies to illustrate flexibility. As a secondary benefit, the Approval Server can route a request simultaneously within both departmental hierarchies. Neither department has to delay until the other has finished routing the request. Whether in a single or parallel Parent-Child process, a rejection from any given approver could reject the request for everyone. Process Administrators should set up notifications to inform each hierarchy when a parallel hierarchy has rejected a request.
109
When you use a Parent-Child process for approval requests, be aware of the following considerations: A Parent-Child process expects a rule defining how to find the next approver. This rule must include the name of the field containing the identity of the parent record and return the Approver List, a string of individuals/roles. Working with Get Next Approver rules on page 168 provides more information about this type of rule and includes specific procedures. When an approver marks an approval request as approved, the Approval Server routes the request to the parent of that approver. There is no waiting for all approvals to be completed before forwarding the requisition to the next approver (based on the Get Next Approver rule). In generating the first Approver List for a Parent-Child process, the Approval Server assumes that the previous approver is the originator of the approval request. This means that the parent of the approval request originator becomes the first approver.
In the second illustration, imagine that a request for a soft drink machine in a company courtyard must be approved by the refreshment committee, the landscape committee, and finally the maintenance committee.
Figure 7-10: Level process with three levels
None of the committees reports to another, nor are there any fixed relationships, but the order in which the committees see the request is defined by the Level process. A Level process does not dictate the number of approvers on each level, nor how many signatures must be gathered within a given level. You could set up a level consisting of one person, or many. The approvers for a given level can be made up of individuals or roles. You can set up routing to the next level to require only one approval, to require signatures from any number of individuals on a given level. Unlike Parent-Child, Level processes are not concerned with relationships. A Level process is concerned only with the order in which the approvals are generated. In a Level process, a request must be approved within each level before it passes to the next level, in order. A Level process uses a level value to indicate the position of individuals or roles. The value in the level field is used by the Approval Server to determine an approval sequence, starting with Level 0, with 1000 as the highest level. The Approval Server skips over any unused levels when it proceeds to a new level value.
111
When you use a Level process for approval requests, be aware of the following considerations: A Level process requires a rule defining how to find the next approver. This rule must return two values: a level indicator, and a string of individuals or roles. Working with Get Next Approver rules on page 168 provides additional information and specific procedures for defining this type of rule. The Process Administrator needs to set up rules to determine whether a request should appear to more than one person on a given level. For example, should the process ask all committee members to approve a request, or should the process route requests only to the executive council, or only to the chairperson alone?
Guide for Users and Administrators Figure 7-11: Routing two requests in the same Ad Hoc process
An Ad Hoc process gives routing authority to each approver without requiring the Process Administrator to set permissions for every individual or role. Ad Hoc overrides are appropriate when specific people should have the option to route a request, overriding an otherwise fixed process. When you set up Ad Hoc processes, consider that Get Next Approver rules are not used by an Ad Hoc process. Individual approvers must enter the name of the next approver, if any. If you need to add another approver to any level, you can use the Parameterized Get Next Approver rule.
Note: Each approver in an Ad Hoc process must enter the exact AR System login ID of the next approver. Process Administrators can prevent errors due to typos if your BMC Remedy Administrator constructs menu lists containing the appropriate Ad Hoc approvers.
113
Level
Optional.
Ad Hoc
No. All routing determined by the current approver. Custom, as determined by the Process Administrator.
Parameterized Get Next Approver rule determines the level of next approver. Custom, as determined by the Process Administrator.
Not applicable.
Rule-based
Optional.
Notifications
Like other parts of the AR System, the Approval Server can use notifications to keep people informed when they need to respond to an approval request. Process Administrators can set up notifications to be sent at any step of an approval process, and to any individual or role. The following examples can help you identify notifications that are needed within your processes. When an approver needs to respond to a request. When an approver responds with an approval or rejection. When an approver has not responded to a request for a duration. When a requester needs to supply more information to an approver. When an error occurs. When an approval request is rejected after it has been approved by at least one person. When an approval request passes a certain step in the approval cycle. When an approver puts the request on hold. When the normal approval cycle has been overridden by an approver or the Process Administrator. When no action occurs for a certain duration. When a no action notification is ignored.
Notifications
115
AR System Approval Server offers the flexibility to notify people in the manner that suits your workflow. As Process Administrator you can configure Approval Server notifications to be delivered by email, by the AR System Alert client, or by the method set as the users default notification mechanism. Review these procedures for setting up approval notifications: Enable the events for which the Approval Server sends notifications using the form described in AP:Admin-ServerSettings on page 272. You must enable notifications on this form, or notifications are not sent regardless of the other Approval Server settings. Configure the Approval Server to send approver notifications using the procedure Using approval notifications on page 127. Configure the delay before escalations when no activity occurs using the procedure Use the Signature Escalations tabs to configure settings for actions and notifications when a signature line has been waiting too long without response. For example, you can set up a notification to be sent when a request has been outstanding for two days. on page 146. Configure notifications for More Information Requests using the procedure Entering more information escalations on page 148.
Chapter
117
The following procedures demonstrate using the Approval Server Administration form for both BMC Remedy User and the browser. For the 7.0 release, the web view of the Administration application differs slightly in appearance from the BMC Remedy User view, but their functionality is identical. Nearly all the examples in this chapter show the Approval Server displayed in a browser.
Guide for Users and Administrators Figure 8-1: Administration form (Remedy User)
To use a browser
1 Launch your browser and type in the administration URL for your Approval
Server. See your AR System Administrator for the exact administration URL of your Approval Server. For example, with a web server named acme that is accessing an AR System server named apex, the administration URL might appear as follows:
http://acme/arsys/apps/apex/ApprovalAdminWeb
119
selected components appears. Double-click one of the items on the list to display the form for that record.
3 To delete an existing component, click the appropriate tab and select the
record you want to delete. Click Delete and confirm your intention in the subsequent dialog box.
Note: For components other than Role and Form, you can first select a value in the Show For Process field. This limits the list of items displayed to those associated with the selected process.
form.
2 Click Rename in the navigation pane.
3 From the Rename menu list, select Process to change a process name, or
Form to change a form name. Form renames only the form. Process renames the process, forms, and cross references.
4 Select an item to rename from the From Old Name menu list.
121
5 Enter a new name for the process or form in the To New Name field. Or select
Selecting All updates both currently active and completed detail records. This option takes more time but will make sure that all detail records reference the new name. Selecting Only Active Objects updates only the currently active detail records. This setting applies to existing detail entries in the system. All structured definitions are changed for either setting.
7 Select the Including Object Itself check box to change the name of the object
as the first step of the rename action. By default, this check box is selected.
Note: If you have already manually changed the process or form name, you can clear this check box and only the Approval Server references are updated. Type the original name in the From Old Name field, and in the To New Name field, type the one you have already manually changed. However, this workaround does not update the attached rules.
8 Click Rename to execute the rename action.
Server Settings in the navigation pane. The Server Settings form appears.
Figure 8-4: Server Settings form
2 Select the Approval Debug Mode check box if you want the Approval Server
to generate a log of approval activity. By default, this check box is selected. The log is a text file. For more information, see Approval server debug log on page 124.
3 If needed, enter a name or system path for the debug log file.
The Log File Name field contains the default file location and name. If needed, specify an alternate log file or location.
4 Type a number in the Definition Check Interval field.
This is the number of seconds before the Approval Server checks for changes to process definitions. The system default is 300 seconds. A larger number increases AR System performance. A smaller number is useful while creating and testing a process. A zero (0) in this field causes immediate implementation of a definition.
5 Type a number in the Private AR Server RPC Socket field.
123
This is the port of a dedicated private server to use when accessing the AR System server. Leave this field empty if you do not have a dedicated private server.
6 Type the path for the directory where web forms are stored in the Virtual
Web Document Directory field. Leave this field empty if you do not have the AR System mid tier installed for web-based approvals.
7 Click Save to save your changes.
Once the log is activated, logging starts immediately. By default, the log file is emptied and restarted when you restart the Approval Server or when you reactivate logging after it has been deactivated. Be aware that debugging can generate a large amount of information quickly.
125
Note: This user must be defined as a member of the group Approval Admin, ID 402, in the User form for this AR System server before the settings you make here will take effect.
4 Select Full Admin or Override Only Admin from the Authority menu list.
Full Admingrants this user the ability to modify processes as well as the ability to approve or reject a request regardless of the normal process. Override Only Admingrants this user the ability to approve or reject a request regardless of the normal process.
5 Select one of the four following options from the Notify Method menu list.
No MessageNo message is sent. AlertUsers are notified when they run BMC Remedy Alert. For more information about BMC Remedy Alert, see the Configuring guide.
EmailUsers are notified through email. If the contents of the Send To field do not match an existing user or group definition, the system interprets the field contents as a literal address and sends the notification to that address by SMTP mail (UNIX) or MS-Exchange (Windows). When you use this option, it is possible to send notifications to users not using the AR System, an alias for a group, or an email address representing a program. User DefaultUsers are notified using the default notification method defined in their User record. If the User record does not contain a default notification method, BMC Remedy Alert is used.
6 Select a Covering option.
Selecting All gives the individual administrative capabilities for all processes defined in the Process Definition form. If this is not what you want, select Specific Process and then select a process from the Process Name menu list.
7 Select Active from the Status field menu list.
The Status field allows you to disable administrator capabilities for a specific individual without the need to delete and re-enter information for the same individual should it be needed later. The ability to easily turn administrator capabilities on or off allows you to set up entries for individuals who might need administrator capabilities only on a temporary basis. For example, you can store information for an individual who periodically covers for an administrator.
8 Click Save.
127
WARNING: Activating events on this form does not guarantee that this event will generate a notification or escalation. However, if you do not activate an event on this form, all other notification and escalation settings are ignored for that event.
Select Disabled if you never want the event to trigger a notification. Select Enabled for each event that needs to send a notification. Select Enabled Including Alternate if the event needs to trigger a notification for both the intended approver and any designated alternates.
5 Click the Escalations tab.
Guide for Users and Administrators Figure 8-7: Determine events that trigger escalations
Select the appropriate option buttons to determine which events trigger no escalation, an escalation for approvers, or an escalation for both approvers and alternates.
6 Click Save to save your changes.
The events determined here are now able to trigger notifications and escalations using the Notification form.
Use a name that indicates the type of notification, such as New-Signature Notification.
4 Select the appropriate process from the Process Name menu list.
See Creating a process on page 140 if you have not set up any processes to select.
5 Click the appropriate notification Status.
The Status option allows you to temporarily enable or disable this notification without having to delete or reenter notification entries. See Defining the events to trigger notifications on page 127 to enable and disable which events trigger notifications for the entire process.
6 Select one of the following Notify On options from the menu list.
This option specifies the approval cycle event that triggers the notification.
Notify on event New signature Approve Reject Alternate approve Alternate reject Override approve Event that triggers Default notify list
When a new signature line is Approver list. added to the approval request. When the approval request is approved. When the approval request is rejected. When an alternate approves the approval request. When an alternate rejects the approval request. When a user with override capability approves the approval request. When a user with override capability rejects the approval request. When an administrator performs a global approve, terminating a process for a request. When an administrator performs a global reject, terminating a process for a request. Approver list minus current approver. Approver list minus current approver. Individual Approved for. Individual Approved for. Approver list.
Override reject
Approver list.
Global approve
Approver list.
Global reject
Approver list.
When an approval is reassigned Approver list. to a different approver. When there is an error in the approval signature. When an approval request is cancelled. When a request for more information is fulfilled. Individual who approved or rejected. Approver list. Individual who requested more information.
131
Notify on event
Reject by later level When the approval request is Approver list. rejected after this signature has approved. Cancel at later level When the approval request is cancelled after this signature has approved. Reject by another approver Hold More info When the approval request is rejected by another signature record. When an approval request is put on hold. When more information is requested by an approver. Approver list.
Approver list.
Approver list minus current approver. Approver list minus current approver. Does not include requester.
Still active
When an approval request is in Approver list. an approval pending state and there has been no action. When a Still Active notification Approver list. has been sent and there is still no action. When an approval request is on Approver list. hold in the approval cycle and there has been no action. When a Still Pending notification has been sent and there is still no action. When a Hold notification has been sent, but there is still no action. Approver list.
Still pending
Approver list.
When a Still Hold notification Approver list. has been sent, but there is still no action. When more information has been requested for a approval request and there has been no action. Approver list.
When a Still More Info Approver list. notification has been sent, but there is still no action. When an error in the approval Approver list. cycle has occurred, but there has been no action to correct the error. When a Still Error notification Approver list. has been sent, but there is still no action. When a change occurs that all past approvers should know about. Approver list.
notification. This allows you to define a trigger that is in addition to the Notify On condition.
8 Click the Details tab.
Figure 8-9: Determine the method and content of the notification
133
9 Select one of the following notification options for the Method field: None Alert Send no notification. Users are notified when they run BMC Remedy Alert. For more information about BMC Remedy Alert, see the BMC Remedy User online help. Users are notified by email. If the contents of the Send To field do not match an existing user or group definition, the system interprets the field contents as a literal address and sends the notification to that address by SMTP mail (UNIX) or MSExchange (Windows). When you use this option, it is possible to send notifications to users not using the AR System, an alias for a group, or an email address representing a program. Triggers a filter guide that fires on the required event and sends the notification.
Note: This functionality does not work out of the box. You must
Workflow
add it to your application. For more information, see Enabling workflow-based notifications on page 235. User default Users are notified by the default notification method defined in their User record. If the User record does not contain a default notification method, BMC Remedy Alert is used.
10 Select a Priority for the notification from 0 to 10. This allows users to sort
notification is to be sent. Notifications are sent to users or roles, or the Approval Server can write to a form field.
Notify List Other Send to the default notify list for the selected Notify On option. Specify an individual, a group, a list of individuals, or groups, or a field reference to a field containing individuals or groups.
You can use the field list button to include field values in the subject line.
13 To attach additional field information to the notification, enter or select the
You can use the field list button to include field values in the Message field.
15 For email or User Default notifications, click the Email tab.
You can use the Fields or Keywords menu list to enter a field or keyword. The fields in the Email tab are the same as those used when you create an Email or User Default mechanism in a Notify filter action. For further detailed information about these fields and using email notifications in general, see the information about messages and notifications in the BMC Remedy Email Engine Guide.
Figure 8-10: Defining email notifications
16 Enter the name of the mailbox that you want to handle the notifications if
you do not want to use the default mailbox. You can use a field or a keyword to substitute a mailbox name. This mailbox name should correspond to a valid mailbox configured in the AR System Email Mailbox Configuration form, or at the initial installation of the email engine.
17 Enter information in the From, Reply To, CC and BCC fields.
If you make multiple entries in these fields, separate the entries by hard returns. You can use the following entries in the fields: AR System user logins AR System groups
135
Direct email addresses Include the email domain name if you are entering a users name (for example, Joe.User@acme.com) or a keyword (for example, $USER$@acme.com). A field A keyword The order in which the entries appeared previously is the order in which the email engine does the search for addresses.
18 In the From field, enter the name to be displayed to indicate where the mail
is from.
19 In the Reply To field, if you enter a group name, a reply will be sent to all the
email notification.
21 In the BCC field, enter the names of people you want to receive copies of this
email notification but whose names you want hidden from the other recipients.
22 In the Organization field, enter a company name, an organization, a
keyword, or a field reference to a name that you would like to appear on the email.
23 In the Header, Content, and Footer fields, specify the names of the templates
4 In the Schedule Name field, type in a new name. 5 (Optional) In the Offset Hours field, enter the amount of time to offset the
start time by. This field allows you to calculate business hours into the single 024 hour range that is required by the AR System server.
6 Click the Time Schedules tab. 7 Modify the start and end times, as appropriate for your company. 8 Click Save to save your changes.
137
BMC Remedy Approval Server Figure 8-12: Business time holidays form
4 In the Schedule Name field, type in a new name. 5 In the Holidays field, enter the dates of the holidays observed by your
company. A date format is specified for your AR System server. Be certain to specify the date in the server format or the system might interpret the dates incorrectly.
6 Click Save to save your changes.
Where to go next
Setting up Processes, Rules, and Roles are covered in separate chapters: Chapter 9, Defining an approval process Chapter 10, Defining approval rules Chapter 11, Managing users and roles
Chapter
This chapter describes the procedures to create and modify approval processes. The following topics are provided: Using the Process Definition form (page 140) Creating a process (page 140) Working with existing processes (page 149)
139
Creating a process
This section describes how to create a process using the Process Definition form. In most cases, you need only one process for your approval request, but it is possible to create multiple processes. For an example of an application that uses three separate approval processes, see the Sample Lunch Scheduler form that is described in Sample process descriptions on page 216. Use the following procedures to create an approval process. Each of the tabs on the Process Definition form is described in a separate procedure. You might not need to follow all of the procedures, depending on how you decide to define your approval process.
To create a process
1 Open the Administration form.
See Using the Approval Server Administration form on page 118 for the procedure.
2 Click the Process tab and click the Create button.
Guide for Users and Administrators Figure 9-1: Process Definition formBasic tab
Process names must be unique and have no more than 254 characters (including spaces). It is helpful to make the name descriptive and indicative of the process function.
4 From the Form field menu list, select the AR System application workflow
Parent-Child Level Ad Hoc Rule-Based For a description of the different types of processes, see Approval process types on page 107.
Creating a process 141
You might want to set the status to Inactive during the development of the process and the associated rules. When all the appropriate rules are in place, you can modify the process and set the status to Active.
7 From the Approval Success menu list, select a value.
The value in this field indicates how you want the Approval Server to determine the successful completion of the approval process. The options are:
No more approvers Use this value to indicate that the Approval Server should consider the approval process finished when all signature lines are complete. (A completion rule can also be used to end the process.) As a result, if the option is set to No More Approvers and if you cancel the signature line and there is no other signature, then the request is marked as Approved, not cancelled. Completion rule Use this value to indicate that the Approval Server should expect a Completion rule to determine the successful completion of the approval process. If you select this option, you must create a Completion rule and associate it with this process or the process will never complete.
This field applies only if you are defining an Ad Hoc process or are going to allow Ad Hoc overrides (see step 5 of this procedure for the process type selection). The value you select determines how many signature line records the Approval Server creates when building an approver list.
whether to allow Ad Hoc additions to an approver list by selecting an option from the Allow Ad Hoc Next Approver list. The options are:
Anyone Approver No one Allows anyone to specify the next approver. This includes the requester and approver. Allows only the approver and not the submitter to specify the next approver. Prevents anyone from specifying an Ad Hoc approver.
Note: If you are creating an Ad Hoc process, the Allow Ad Hoc Next Approver field does not apply.
Creating a process
143
10 From the For Self Assignment field, specify how the Approval Server
determines the next approver when the requester is not the person who submitted the approval request. For example, when an assistant enters an approval request for someone else. The options are:
Use get next approver rules To use a Get Next Approver rule to determine the first approver.
Assign to owner if To use the requester as the first approver if the requester is approver defined as a valid approver within the Approval Server. If you select this option, you must define a Validate Approver rule to verify whether the owner is a valid approver. Always assign to owner To use the requester as the first approver in all cases.
11 From the Request Owner Field menu list, select the field identifying the
approver. If the process is an Ad Hoc process or if you specified Anyone for the Allow Ad Hoc Next Approver, then you must specify a field to contain an initial approver value.
13 From the Validate Approvers menu list, choose Yes if an entry in your Next
Approver List field on the approval request must be verified at the time of entry with a Validate Approver rule.
14 From the Require Password list, choose Yes if approvers must enter their
approvers working on this request. For an example of generating a preview list of approvers with the Lunch Scheduler sample application, see Previewing approvers on page 218.
After you create your process, it automatically appears in the defined processes listed in the Administration form. For more information, see Using the Approval Server Administration form on page 118.
Creating a process
145
Use the Signature Escalations tabs to configure settings for actions and notifications when a signature line has been waiting too long without response. For example, you can set up a notification to be sent when a request has been outstanding for two days. This procedure applies to any of the notification priority levels (Normal, Urgent, or Low) of the Process Definition form.
See Creating a process on page 140 for the procedure to open this form.
2 Click the tab for the notification priority level on the Process Definition
Note: If you do not enter parameters for either urgent or low priority notifications, the parameters you enter for normal priority are used. You can use the urgent or low priority sections to enter only parameters that are different than those you set for normal priority.
3 Select or enter the names of the Business Calendar and the Holiday Calendar
you want to use for signature escalation notifications. These names must match existing schedule names from the Business Time Workdays or Business Time Holidays forms. See Configuring business times on page 136 for information about setting up business times.
4 To change the state of an approval request automatically if no signature
action occurs after a specified interval, enter the Automatic Action parameters:
a Enter a number in the After Interval field to indicate when you want the
state changed, and select what this number represents from the Unit list. For example, if you want the state to change two days after the approval request enters a certain state, enter 2 in the After Interval field, and select Day from the Unit list.
b From the Changed State field, use the menu list to select the state that you
want to apply to the approval request. The options are Pending, Approved, or Rejected.
5 If you want to send notifications when a signature line has been outstanding
(in any state) for too long, specify the Notification: Still Outstanding parameters:
a Enter a number in the First Interval field to indicate when you want the
first notification sent, and select what this number represents from the Unit list.
b If you want a second notification sent, enter a number in the Repeat
Interval field and select what this number represents from the Unit list.
6 If you want to send notifications when the approval request remains in a
certain state (Pending, Error, Hold, or More Information) too long, specify the Notification: Still in State parameters:
a Enter a number in the First Interval field for the desired state to indicate
when you want the first notification sent, and select what this number represents from the Unit list.
b If you want a second notification sent, enter a number in the appropriate
Repeat Interval field and select what this number represents from the Unit list.
Creating a process
147
See Creating a process on page 140 for the procedure to open this form.
2 Click the More Info Escalations tab of the Process Definition form.
Figure 9-3: More information escalations
3 Select or enter the names of the Business Calendar and the Holiday Calendar
you want to use for More Information Escalation notifications. These names must match existing schedule names from the Business Time Workdays or Business Time Holidays forms. See Configuring business times on page 136 for information about setting up business times.
4 If you want to send notifications when a signature line has been outstanding
(in any state) for too long, specify the Notifications: Still Outstanding parameters:
a Enter a number in the First Interval field to indicate when you want the
first notification sent, and select what this number represents for the Unit list. For example, if you want the first notification sent two days after the approval request enters the More Information state, enter a 2 in the First Interval field and select Day from the Unit list.
b If you want a second notification, enter a number in the Repeat Interval
field and select what this number represents from the Unit list.
5 Click Save to save your process.
Modifying processes
Follow these steps to modify an existing process.
To modify processes
1 Open the Administration form.
See Using the Approval Server Administration form on page 118 for the procedure.
2 Select the Process tab. 3 Double-click the process you want to modify or select the process and click
the View button. The Process Definition form appears (Figure 9-4 on page 150).
149
Deleting processes
Follow these steps to delete an existing process.
Note: The delete operation is permanent and cannot be undone. When you delete a process, all of the associated rules are deactivated.
To delete processes
1 Open the Administration form.
See Using the Approval Server Administration form on page 118 for the procedure.
2 Select the Process tab.
5 Verify the name of the process and click Yes to delete this approval process.
Renaming processes
Follow these steps to rename a process.
To rename processes
1 Open the Administration form.
See Using the Approval Server Administration form on page 118 for the procedure.
2 Click Rename in the navigation pane.
151
3 From the Rename menu list, select Process to change a process name.
Name field.
6 From the Update menu list, select an update action for existing detail entries:
Selecting All updates both currently active and completed detail records. This option takes more time but will make sure that all detail records reference the new name. Selecting Only Active Objects updates only the currently active detail records. This setting applies to existing detail entries in the system. All structured definitions are changed for either setting.
7 Select the Including Object Itself check box to change the name of the object
as the first step of the rename action. By default, this check box is selected.
Note: If you have already manually changed the process or form name, you can clear this check box and only the Approval Server references are updated. Type the original name in the From Old Name field, and in the To New Name field, type the one you have already manually changed.
8 Click Rename to complete the action.
Chapter
10
This chapter describes how to create and modify approval rules. The following topics are provided: Using the Rule Definition form (page 154) Working with Auto-Approval rules (page 159) Working with Self-Approval rules (page 162) Working with Prep Get Next Approver rules (page 165) Working with Get Next Approver rules (page 168) Working with Parameterized Get Next Approver rules (page 174) Working with Get Authority rules (page 181) The value in this persons Signature Dollar Limit field from the Signature Authority form will be written to a temporary field named Temp Decimal 1. The value in the temporary field is then available for use by any SelfApproval or Completion rules. (page 183) Working with Get Authority Self rules (page 185) Working with Completion rules (page 187) Working with Signature Accumulator rules (page 189) Working with Statistical Override rules (page 193) Statistical Decision-Making approvals in a sample application (page 196) Working with Approval Process Done rules (page 201) Working with existing rules (page 203)
153
Creating a rule
To create a new rule you need to open the Rule Definition form from the Administration form. Use the following procedure for opening the form.
To create a rule
1 Open the Administration form.
See Using the Approval Server Administration form on page 118 for the procedure.
2 Click the Rule tab and click the Create button.
Guide for Users and Administrators Figure 10-1: New rule definition
3 Read the following sections covering the tabs found on this form, or proceed
directly to the appropriate procedure for the type of rule you want to define. Working with Auto-Approval rules on page 159 Working with Self-Approval rules on page 162 Working with Prep Get Next Approver rules on page 165 Working with Get Next Approver rules on page 168 Working with Parameterized Get Next Approver rules on page 174 Working with Get Authority rules on page 181 Working with Get Authority Regular rules on page 183 Working with Get Authority Self rules on page 185 Working with Completion rules on page 187 Working with Signature Accumulator rules on page 189 Working with Statistical Override rules on page 193 Working with Approval Process Done rules on page 201 Working with existing rules on page 203
155
157
Depending on the specific rule type, the Set Fields tab provides the following action assignment types:
Value Query Allows you to assign a value to a particular field. Allows the specification of a form (from the current or another server) and a qualification. You can assign the value of any field from the form. If there is no match for the qualification, a NULL value is assigned. If there are multiple matches, the value assigned depends on the If Multiple Rows setting on the Basic tab. Allows the specification of an SQL command to be run on either the AR System server or another database. You can assign the value from any returned column. If the command finds no entries, a NULL value is assigned. If it finds multiple entries, the value assigned depends on the If Multiple Rows setting on the Basic tab. Allows the specification of a process to be run on the AR System server. If the command returns an empty string or an error, a NULL value is assigned. Allows you to specify an AR System filter. See the Workflow Objects guide for more information about filters.
SQL
Process
Other
This example illustrates the Query assignment type allowing you to define a query to another form to retrieve additional data.
159
This is the name of the process defined for your approval request workflow. All rules must be attached to a process to be active.
4 (Optional) Select a process instance ID.
A process instance ID is a unique GUID that identifies each process. This is especially useful if processes use the same name. All workflow that needs to see this process can now see the GUID and not just the name. You can now change process names as needed, without affecting underlying workflow.
5 Select Auto-Approval from the Rule Type field menu list.
As soon as you select a rule type, the Rule Definition form changes to display the fields appropriate for the specific type of rule. Fields that apply to the rule have a white field box. Fields that do not apply are gray.
6 Select a rule status from the Status field menu list.
Select either Active or Inactive in this field to indicate the status of the rule. While you are developing a set of rules for a process, it might be helpful to use the Inactive status and then later activate the rules when you have completed all the necessary rules.
7 Enter an execution order number in the Order field.
This number determines the sequence if you have two or more AutoApproval rules for a specific process.
You can type the condition statement or you can build it by using the qualification bar and list. For more information, see the Workflow Objects guide. When the qualification is met, the rule actions execute. The rule condition should test for a specific field value; for example, checking if the value for an Estimated Total field is less than $50.00. See the AutoApproval rule example that follows for a typical auto-approval rule.
9 Enter an Audit Text message, if applicable.
This is the message written to the audit diary field if the rule passes. If you do not enter a message, a default message is written to the audit log.
10 Click Save to save your changes.
In this example, the value in the approval request Total field is tested to see if it is less than $15. In addition, if this rule passes, the customized audit trail message, as shown in the Audit Text box, is written to the audit log.
161
This is the name of the process defined for your approval request workflow. All rules must be attached to a process to be active.
4 (Optional) Select a process instance ID. 5 Select Self-Approval from the Rule Type field menu list. 6 Select a rule status from the Status field menu list.
Select either Active or Inactive to indicate the status of the rule. While you are developing a set of rules for a process, it might be helpful to use the Inactive status and then later activate the rules when you have completed all the necessary rules.
7 Type an execution order number in the Order field.
This number determines the sequence if you have two or more Self-Approval rules for a specific process.
8 Type the rule condition in the Rule field text box.
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. The rule condition defines the criteria under which self-approval is allowed. Build a condition statement that tests for a specific field value. For example, test to see if a signature authority field value is $100.00 and the total approval request amount is less than or equal to $100.00. The condition can reference any value of the current approval request record, including any values retrieved by the operations of a Get Authority Self rule. Self-Approval rule example on page 164 provides a look at a typical Self-Approval rule.
9 Enter an Audit Text message, if applicable.
Enter a message to be written to the audit trail log when this rule is used. This message can include embedded field references that are filled when the rule condition passes. If you leave the Audit Text field blank, a default message is written to the audit trail log.
10 Click Save to save your changes.
163
In addition to the rule condition action, this sample rule includes a customized audit trail message to be written to the audit log in the event that the rule passes.
Figure 10-5: Self-Approval rule
Rule Name field. Rule names must be unique. There is no enforced convention for specifying rule names, but it is helpful to make the name descriptive and indicative of the rule function. Names can be as many as 30 characters, including spaces.
3 Select the process name from the For Process menu list.
Select either Active or Inactive to indicate the status of the rule. While you are developing a set of rules for a process, it might be helpful to use the Inactive status and then later activate the rules when you have completed all the necessary rules.
7 Type an execution order number in the Order field.
This number determines the sequence if you have two or more Prep Next Approver rules.
165
This is an optional step. Use this field for defining a conditional statement for the execution of the rule. You can type the conditional statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
9 Click the Set Fields tab. 10 Select a value from the Set Fields Type field menu list to indicate the Set Field
action assignment. See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
11 If appropriate, select a form name from the From Form field menu list.
This value indicates where the rule should search for a matching approver name to validate the user entry.
12 If appropriate, select a value from the On Server field menu list to indicate
13 If appropriate, type the server name in the Server field. 14 Enter a qualification statement to test for a valid approver. 15 Click Save to save your changes.
167
The Approval Server keeps track of the current approver level of each approval request as it goes through the approval cycle. When defining a Get Next Approver rule for a level process, be aware of the following considerations: You must identify the field containing the level identifier. If you define a qualification that includes a clause to retrieve only entries with a level greater than the current level, you save processing time by allowing the Approval Server to skip over individuals or roles in the previous levels. This type of clause is not required, as previous level entries are simply ignored if they are retrieved. For more information, see Level processRouting without approver relationships on page 110.
169
For more information, see the following sections: Working with Parameterized Get Next Approver rules on page 174. Ad HocApprovers choose who is next on page 112.
This field value determines what occurs when more than one approver is returned by the Get Next Approver rule. The following choices are available:
One Must Sign A single signature-line record is created and only one of the approvers listed in the record is required to act upon the approval request to consider the record complete. A separate signature-line record is created for each individual in the approver list, including individuals within a role. These require all of the approvers retrieved by the Get Next Approver rule to act upon the approval request. Leaves this field blank.
Clear
10 Select a value from the Next Approver Rule Is field menu list.
The value in this field determines how retrieved data is treated, with regards to the current approver list, when there are multiple Get Next Approver rules. This field is generally used for a rule-based process that has a set of Get Next Approver rules for building an approver list. The following choices are available:
Additive Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, and further rules are to be processed. Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, but no further rules are to be processed. Select to indicate that this rule assigns the entire approver list, and no further rules are processed. In addition, if a previous rule created an approver list, that list is ignored. Leaves this field blank.
Ending
Exclusive
Clear
171
This is an optional step. Use this field for defining a conditional statement for the execution of the rule. You can type the conditional statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. See Example of Get Next Approver rule on page 172 for an example of a rule condition.
12 Click the Set Fields tab on the Rules Definition form. 13 Select a value from the Set Fields Type field menu list to indicate the Set Field
action assignment. See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
14 Select a form name from the From Form field menu list.
This value indicates where the rule should search for a matching approver name to validate the user entry.
15 Select a value from the On Server field menu list to indicate the form
location.
Current Alternate Select to indicate the form resides on the current server. Select to indicate the form resides on a different server. You must indicate the server by typing its name in the Server field.
16 Enter a qualification statement to test for a valid approver. 17 Click Save to save the rule.
In addition, the Next Approver Rule Is field is set to Ending, meaning that no other Get Next Approver rules will be processed after this one. On the Set Fields tab for this rule, the current approver ($Approver$) has been defined as the person logged in and acting upon the requisition at the time this rule is evaluated (see the statement in the Qualification field). This person could be the approval request submitter or it could be an approver. Once this rule has identified the current approver, it determines that persons manager by locating a value in $Manager Login Name$ from the APSample:Signature Authority form and setting the value in the Next Approver field on the approval request record.
Figure 10-7: Example of a Get Next Approver rule
173
At Stage 2, the Parameterized Get Next Approver rule lets approver Barbara decide Ad Hoc that approver Frieda needs to be included along with Debbie. You use the Parameterized Get Next Approver rule in combination with the Add-PGNA-Values command. This command is used by the application to provide the variable values for the Parameterized Get Next Approver rule type. (For more information, see Add-PGNA-Values on page 259.) The Parameterized Get Next Approver rule works exactly like Get Next Approver rule, with the following exceptions: Run-time variables can be part of the qualification and Set Fields operations. Approvers can be added to any level. After the Get Next Approvers rules are executed, the server executes all Parameterized Get Next Approvers rules. If there are rules, but the current record does not have any parameters, then the rules will be skipped. For more information about different approval types, for example, ParentChild, Level, or Rule-Based processes, see Working with Get Next Approver rules on page 168.
This field value determines what occurs when more than one approver is returned by the Parameterized Get Next Approver rule. The following choices are available:
One Must Sign A single signature-line record is created and only one of the approvers listed in the record is required to act upon the approval request to consider the record complete. A separate signature-line record is created for each individual in the approver list, including individuals within a role. These require all of the approvers retrieved by the Get Next Approver rule to act upon the approval request. Leaves this field blank.
Clear
175
10 Select a value from the Next Approver Rule Is field menu list.
The value in this field determines how retrieved data is treated, with regards to the current approver list, when there are multiple Get Next Approver rules. This field is generally used for a rule-based process that has a set of Get Next Approver rules for building an approver list. The following choices are available:
Additive Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, and further rules are to be processed. Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, but no further rules are to be processed. Select to indicate that this rule assigns the entire approver list, and no further rules are processed. In addition, if a previous rule created an approver list, that list is ignored. Leaves this field blank.
Ending
Exclusive
Clear
This setting allows run-time variables to be part of the Run If qualification and Set Fields operations.
12 Enter the rule condition in the Run If text box.
This is an optional step. Use this field for defining a conditional statement for the execution of the rule. You can type the conditional statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. See Defining Parameterized Get Next Approver rules on page 174 for an example of a rule condition.
13 Click the Set Fields tab on the Rules Definition form. 14 Select a value from the Set Fields Type field menu list to indicate the Set Field
action assignment. See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
15 Select a form name from the From Form field menu list.
This value indicates where the rule should search for a matching approver name to validate the user entry.
16 Select a value from the On Server field menu list to indicate the form
location.
Current Alternate Select to indicate the form resides on the current server. Select to indicate the form resides on a different server. You must indicate the server by typing its name in the Server field.
17 Enter a qualification statement to test for a valid approver. 18 Click Save to save the rule.
AP:Details form (for example, 000000000000001). User A decides to add Frank Williams as an approver at a future level, for example, level 4.
Step 3 User A uses the Add-PGNA-Values command to send a signal to the
Step 4 The Approval Server receives this signal, and stores the data in the Param
177
Step 5 The next time the Approval Server executes the Get Next Approvers rules, it
also executes the Parameterized rules. While executing the parameterized rules, it retrieves the rules values from the Param Data field. It retrieves 4/ Frank? Williams and parses this into %1=4 and %2="Frank Williams.
Step 6 The Approval Server substitutes these values into the parameterized rules. Run If qualification Set Fields
$Level$ = 4 $Next Approver$ = Frank Williams
If the condition matches, the Set Fields action is executed. If the condition never matches and the regular Get Next Approver rules do not return any approvers, then the engine checks for the Guaranteed Add flag. If this is set to yes, then these rules will be executed now, even though the Run If condition is not satisfied. Since this is a standard rule type, it will also be executed when a preview is being generated, and so these Ad Hoc additions will be visible in previews as well.
Figure 10-8: Example of a Parameterized Get Next Approver rule
179
10 Select a value in the Set Fields Type field to indicate the action assignment.
See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
11 Select a form name in the From Form field.
This value indicates where the rule should search for a matching approver name to validate the user entry.
12 Select a value for the On Server field to indicate the form location. 13 Enter a qualification statement to test for a valid approver. 14 Click Save to save the rule.
menu list.
4 (Optional) Select a process instance ID. 5 Select Get Authority from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field. 8 Enter the rule condition in the Run If text box, if applicable.
The Set Field Type indicates the type of assignment to be used for the rule action. See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
11 Select a form name from the From Form field menu list.
This value indicates where the rule should search for the requested data; for example, the Signature Authority form.
181
12 Select a value from the On Server field menu list to indicate the form
location.
13 Enter a qualification statement to define the parameters for retrieving the
authority data. For example, if you want to retrieve the current approvers signature authority limit, you would define a qualification statement that sets $Approver$ (current approver) to equal the Login Name (name of the person currently acting upon the approval request).
14 Enter the names of the fields to receive the data and the names of the fields
where the data is located. You can use the field list button to the right of each of these fields to select the appropriate field names.
15 Click Save to save your changes.
The value in this persons Signature Dollar Limit field from the Signature Authority form will be written to a temporary field named Temp Decimal 1. The value in the temporary field is then available for use by any Self-Approval or Completion rules.
menu list.
4 (Optional) Select a process instance ID. 5 Select Get Authority Regular from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable. 8 Enter the rule condition in the Run If text box, if applicable.
183
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. The section Example of a Get Authority Regular rule on page 184 provides a look at a typical Get Authority Regular rule.
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type field menu list.
The Set Field Type indicates the type of assignment to be used for the rule action. See Using the Set Fields tab on the rule definition form on page 157 for a description of choices available.
11 Select a form name from the From Form field menu list.
This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form.
12 Select a value from the On Server field menu list to indicate the form
location.
13 Enter a qualification statement to define the parameters for retrieving the
authority data. For example, if you want to retrieve the current approvers signature authority limit, you would define a qualification statement that sets $Approver$ (current approver) to equal the Login Name (name of the person currently acting upon the approval request).
14 Enter the names of the fields to receive the data and the names of the fields
where the data is located. You can use the field list button to the right of each of these fields to select the appropriate field names.
15 Click Save to save your changes.
The value in the temporary field is then available for use by Completion rules.
Figure 10-11: Get Authority Regular rule example
185
3 Select the associated approval request process from the For Process field
menu list.
4 (Optional) Select a process instance ID. 5 Select Get Authority Self from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable. 8 Enter the rule condition in the Run If text box, if applicable.
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type field menu list.
The Set Field Type indicates the type of assignment to be used for the rule action. See Using the Set Fields tab on the rule definition form on page 157 for a description of available choices.
11 Select a form name from the From Form field menu list.
This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form.
12 Select a value from the On Server field menu list to indicate the form
location.
13 Enter a qualification statement to define the parameters for retrieving the
authority data. For example, if you want to retrieve the current approvers signature authority limit, you would define a qualification statement that sets $Approver$ (current approver) to equal the Login Name (name of the person currently acting upon the approval request).
14 Enter the names of the fields to receive the data and the names of the fields
where the data is located. You can use the field list button to the right of each of these fields to select the appropriate field names.
15 Click Save to save your changes.
187
Completion rules usually are teamed with Get Authority or Get Authority Regular rules. The authority rules are used to retrieve information about an individuals or roles authority from other forms, such as signature limits, and to make it available for use by Completion rules.
menu list.
4 (Optional) Select a process instance ID. 5 Select Completion Rule from the Rule Type field menu list.
As soon as you select a rule type, the Rule Definition form changes to display the fields appropriate for a Completion rule.
6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable.
Execution order applies to a set of Completion rules for a given process. If you are only defining a single Completion rule, the Order field might be left at zero.
8 Enter the rule condition in the Rule text box. 9 Click the Save button to save the basic information for the rule.
In this instance, the temporary field (Temp Decimal 1) contains the current approvers signature limit, as retrieved by a Get Authority or Get Authority Regular rule. The estimated total of the approval request is being compared to this signature limit. You must define a Get Authority or a Get Authority Regular rule for the Completion rule to work correctly in this example.
Figure 10-13: Completion rule
189
Note: The server automatically populates the Total fields with the number of signature records in Pending, Approved, Rejected, Hold, More Information, Cancelled, Error, and Closed states. These totals should covers the majority of the cases of administrators who want to implement statistical rules. However, you can define Signature Accumulator rules in those cases where a simple count does not suffice. Signature Accumulator rules are directly tied to the Statistical Override rules in that the override rules use the results of the accumulator rules. For more information, see Get authority on page 104.
menu list.
4 (Optional) Select a process instance ID. 5 Select Signature Accumulator from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable. 8 Enter the rule condition in the Run If text box, if applicable.
The values used in the assignment might include static values, arithmetic operations, keywords, the results from functions, and values from the signature record, using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
190 Chapter 10Defining approval rules
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type field menu list.
The Set Field Type indicates the type of assignment to be used for the rule action. See Using the Set Fields tab on the rule definition form on page 157 for a description of available choices. If you select a Query type, select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form. If you select a Query or SQL type, select a value from the On Server field menu list to indicate the form location.
11 Enter a qualification statement to define the parameters for retrieving the
authority data. For example, if you want to retrieve the current approvers signature authority limit, you would define a qualification statement that sets $Approver$ (current approver) to equal the Login Name (name of the person currently acting upon the approval request).
12 Enter the names of the fields to receive the data and the names of the fields
where the data is located. You can use the field list button to the right of each of these fields to select the appropriate field names.
13 Click Save to save your changes.
Here the server might be processing something that had already been changed. For example, if an approver has rejected the request, the Approval Server would apply the Set Fields operation. In this case, when one approver rejects the approval, it runs the rule for each signature line. If the server finds another rejection, the approval is rejected.
191
BMC Remedy Approval Server Figure 10-14: Signature Accumulator rule example
For each signature record, each Signature Accumulator rule is applied (provided the Run If qualification passes). After all rules have been applied for the given signature, the Approval Server moves to the next signature and applies the rules accordingly. Again, it is important to know that the Approval Server automatically provides counts for the current signatures in each state (for example, Total Pending, Total Approved, and so on). For this reason, you as the process author might be able to skip defining the Signature Accumulator rules altogether. You can use the Set Fields operation to also look up information from another form and pull values into the calculation. This might be applicable if you want to apply a weighting to a particular approver. For example, a list of signatures might include one individual who has ultimate authority along with additional approvers who carry the same weight, when combined, as the one individual.
menu list.
4 (Optional) Select a process instance ID. 5 Select Statistical Override from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable.
The execution orders of the rules determine the order in which they are applied.
193
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type field menu list.
When you select a Set Fields Type, Field Name becomes automatically filled in with Statistical Override. See Using the Set Fields tab on the rule definition form on page 157 for a description of available choices. If you select a Query type, select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form. If you select a Query or SQL type, select a value from the On Server field menu list to indicate the form location.
11 Enter a qualification statement to define the parameters for retrieving the
authority data. For example, if you want to retrieve the current approvers signature authority limit, you would define a qualification statement that sets $Approver$ (current approver) to equal the Login Name (name of the person currently acting upon the approval request).
12 Type one of the following values into the Value field:
Approved Rejected You could also enter the corresponding integer index. If you enter any string value other than Approved or Rejected, you will not be able to save the rule. How the Statistical Override value for a particular request is derived might include static values, arithmetic operations, keywords, the results from functions, and values from the detail-signature record the Approval Server is processing from the AP:Detail-Signature form.
13 Click Save to save your changes.
The Run If qualification determines if a rule for a process applies. This means if more than one person rejects the request (every person rejecting the request increments $Temp Integer 2$ by one), the rule can now run the Set Fields operation. In our example, the Set Fields then sets a hidden display-only field (Statistical Override) on the AP:Detail form with a Rejected value. Here you could also set the Statistical Override field with field selection values like Approved. If more than two people reject the request, the approval is automatically rejected and the rest of the approval process is not run.
Figure 10-15: Statistical Override rule example
195
In our example, after the Statistical Override rule sets the Statistical Override field to Rejected, the following occurs: All applicable, pending signature records are cancelled. No further Statistical Override rules are processed.
For example, type A really nice new laser printer at Fry's costs
$600.
6 Type the names of three sample users in the Initial Approvers field.
Since this is an Ad Hoc process, every approver must be chosen manually. Use Jack Miller, Larry Goldstein, and Violet Anderson. Type a semicolon between each approvers name.
7 Click Save to save your request for a new computer.
With statistically-driven approvals, how an approver responds to a request enters a new phase in the approval process.
The signature accumulator rules have been designed to generate the total signature authority for all the approvals. One statistical override rule (Issue Statistical Approval) preempts the approval process to approve if it finds that the total signature authority is more than $500. The other statistical override rule (Issue Statistical Boundary Condition) checks to see if there are any more signatures open. If there are no more signatures open and the $500 signature authority was not reached, then this rule preempts the approval process to reject the request. This example shows in a very simple way how process administrators need to cover all possibilities while designing statistical override rules. In this example, the Approval Server behaves in the following manner: If the signature authority => $500, approve the request. If there are no more signatures open, reject the request. As shown in Figure 10-16, approvals are variously weighted in the APSample:Signature Authority form with the following Signature Dollar Limit values:
Figure 10-16: Dollar signature weights
197
For example, these users have the following signature authority: Jack Miller can approve requests for up to $100.00. Larry Goldstein can approve requests for up to $500.00. Violet Anderson can approve requests for up to $2000.00. The quickest way to understand how statistically-driven approvals work is to see Franks request in the AP:Detail-Signature form. (However, you could also individually approve Franks request in Approval Central as, respectively, Jack Miller, Larry Goldstein, and Violet Anderson to see the effects of the statistical rules.)
8 From BMC Remedy User, log in to the appropriate AR System server as
The approval is pending for Jack Miller, Larry Goldstein, and Violet Anderson.
12 To see how these signatures are weighted, approve the signature for Jack
Miller, save the request, then press F5 to refresh the query. Because Jacks signature authority is weighted at $100, the approval is still pending for either Larry and Violets signatures to meet the $500 qualification, as shown next. As a result, if either Larry or Violet approve the request, Franks approval is done.
Guide for Users and Administrators Figure 10-17: Dollar signature weights
On the other hand, Violets signature authority was weighted so that she could have simply approved Franks request outright without needing either Larry or Jacks approval.
199
This qualification has to be chosen carefully because the selection list contains fields from multiple forms. The $Approvers$ field must be from the AP:Signature form. The Issue Increment Signature Limit rule maintains a total of all the signature authorities. The Run If condition runs these rules if a user approves a request:
$Approval Status$ = "Approved"
This condition is qualified against all the open signatures. (By running it on the three-way application - detail - signature join form). You should verify that this condition works on the fields from the AP:Signature form. The example uses a process to approve a request after the weight of the approvals exceeds $500. This weight can be picked up from another form (in this case AP:Signature Authority).
When the Run If condition has been met, the preempted decision is specified on the Set Fields tab. The only field that can be set in a Statistical Accumulator rule is the Statistical Override field. The only values for this field are Approved or Rejected. You can provide these values directly or use an expression that evaluates to these values. Any value other than these Approved or Rejected results in an error state indicated on the Detail request. The sample also includes the Issue Statistical Boundary Condition rule which checks for any pending signatures. The Run If condition checks if the server needs to wait for any more responses. If the state is anything other than Pending, More Information, or Hold, the request is considered Done. If the Approval Server is not waiting for any responses, the Statistical Override field is set to Rejected.
201
2 Enter a name for the rule (or update the existing name if necessary) in the
menu list.
4 (Optional) Select a process instance ID. 5 Select Approval Process Done from the Rule Type field menu list. 6 Select a rule status in the Status field. 7 Type an execution order number in the Order field. 8 Select one or more rule conditions from among the radio buttons: Approved,
Rejected, Cancelled, or Error. The rule executes when the approval detail record is put in the selected state.
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type menu list.
The Set Field Type indicates the type of assignment to be used for the rule action. See Using the Set Fields tab on the rule definition form on page 157 for a description of the available values.
11 Type the appropriate Field Name and Value to change the status of the
approval request.
12 Click Save to save the rule.
Guide for Users and Administrators Figure 10-18: Approval process done
Rule trigger
203
If you leave the field blank, all the rules for all processes will be displayed when you click the Rule tab.
3 Scroll down the page to view the process diagram.
Figure 10-19: Approval process diagramRules tab
4 Click a rule link in the process diagram to view the rules that execute in the
process. In this example, the Show For Process field was left blank, so that all the processes defined in the system appear in the Rules tab. If you clicked the Next Approver rule link, the Rules tab in the Administration window redisplays so that only the Get Next Approver rules appear, as shown in Figure 10-20. You can now easily modify only the Get Next Approver rules.
Guide for Users and Administrators Figure 10-20: Rules redisplayed after clicking Rule button
5 Click Show All to redisplay all the available rules. You can also click an empty
space in the process diagram. All the rules for the selected process (or processes) will reappear in the Rules tab.
Modifying rules
Follow these steps to modify an existing rule.
To modify rules
1 Select the Rule tab on the Administration form and click the Refresh button. 2 If needed, filter the rules displayed by clicking a rule button in the process
diagram.
3 Double-click a rule or select a rule and click the View button.
The rule appears in a Rule Definition window and the current values for the rule are shown.
205
4 Modify the appropriate rule fields by using the procedures described under
Deleting rules
Follow these steps to delete an existing rule.
Note: The delete operation is permanent and cannot be undone.
Be aware of any rule dependencies before deleting a rule. For example, SelfApproval and Completion rules might depend on a Get Authority, Get Authority Regular, or Get Authority Self rule. If the Get Authority (Self and Regular) rule is deleted, the dependent rule will no longer function as designed. To delete rules
1 Follow steps 1, 2, and 3 of Modifying rules on page 205 to display a list of
rules.
2 Click the rule you want to delete. 3 Click the Delete button.
The rule is deleted and will no longer appear in the list of rules.
Chapter
11
This chapter describes how to define user capabilities and roles for use by the Approval Server in the approval process. The following topics are provided: Defining roles (page 208) Defining alternate approvers (page 209) Assigning process override capability (page 211)
207
Defining roles
The following procedure takes you step by step through the fields on the AP:Role form.
To define roles
1 Click the Role tab on the Administration form and click Create.
Note: See Using the Approval Server Administration form on page 118 to learn how to use the Administration form.
The name should be descriptive of a job or a responsibility. For example, MIS Management would be more descriptive than just Managers (unless you wanted to create a role that was inclusive of all managers in your company).
3 Select an option from the If Multiple Approvers field menu list.
The option you select determines how many signature line records the Approval Server creates for the role when building an Approver List. The options follow.
One must sign Use this value to create a single signature line record for the role. The signature line is complete when one of the members of the role acts upon the approval request. Use this value to create a separate signature line for each member of the role. This option is overridden when the If Multiple Approver setting for the process is defined as One must sign. When this is the case, the role follows the One must sign action. See Creating a process on page 140 for more information about the If Multiple Approver setting for processes.
Note: If you include a role on the member list of another role, the If Multiple Approvers option of the parent role, in some cases, takes precedence. For example, if Role A is defined with If Multiple Approvers set to All must sign and you include Role A in the member list of Role B, which is defined with If Multiple Approvers set to One must sign, the settings for Role B are the ones used by the Approval Server.
4 Select a value from the Status field menu list.
Type valid user names or roles in the Member List box, separating entries with a semicolon or a hard return. Click the Text Box button to open an expanded text box. This field has a maximum length of 255 characters.
6 Click the Save button to save the record.
209
This name defaults to the name of the current user, but it can be changed to another name if you have the appropriate system capabilities, such as full process administrator or AR System administrator.
4 Type a date in the Start Date field.
Select either Yes or No. If you select Yes, a notification is sent to both the person identified and to anyone designated as an alternate for that person.
7 Select one of the Covering option buttons. All Specific Process Use this option to authorize a user as alternate for all the processes of the person indicated in the For field. Use this option to authorize a user as alternate for one specific process. The Process field becomes enabled so you can specify which process this alternate is authorized for. If this person is to be alternate for more than one process, you must create a separate alternate record to authorize each process. 8 Click Save to save the Alternate information.
211
3 Enter a valid user name in the Individual field. 4 Select Override Only Admin from the Authority field menu list. 5 Select an option from the Notify Method field menu list.
This selection indicates how messages are to be sent to the designated person. Select one of the following options:
None Alert No message is sent. Specified users are notified when they run AR System Alert. For more information about the AR System Alert, see the BMC Remedy User online help. Specified users are notified using email. The specified users are notified using the default notification method defined in the User record. If the User record does not contain a default notification method, the Notification Tool is used.
6 Click one of the Covering option buttons. All Specific process Use this option button to authorize a user as alternate for all the processes of the person indicated in the For field. Use this option button to authorize a user as alternate for one specific process. The Process field becomes enabled so you can specify which process this alternate is authorized for. If this person is to be alternate for more than one process, you must create a separate alternate record to authorize each process. 7 Select a value from the Status field menu list.
Chapter
12
213
The requester specifies information about the customer, the restaurant, and the number of attendees. These choices populate fields containing details about the total costs and some information about the customer and the customers current state with the company. When a request is entered, it is routed for approval. Lunch Scheduler includes three different approval processes chained together and uses three different filters with Run Process commands to start the processes: Management Cost Authorization is a managerial approval based on the total cost of the lunch. The request is routed along the management chain until a manager with sufficient dollar authority approves. The APSample:Start Cost Approval filter uses the following Run Process command: Application-Command Approval New-Details -t "Management Cost Authorization".
Major Account Level Approval is a review by the major and enterprise account teams if the account is a major or enterprise account. The APSample:Start Level Approval filter uses the following Run Process command: Application-Command Approval New-Details -s "$SCHEMA$" -e "$Request ID$" -t "Major Account Level Approval". Special Overdue Approval is a special review if the account is currently overdue. The company has decided that taking a customer to lunch who is currently overdue needs special permission. The AP-Sample:Start Overdue Approv filter uses the following Run Process command:
Application-Command Approval New-Details -t "Special Overdue Approval".
Requests are submitted, go through the appropriate approval processes enforcing the business rules of the companyand when approved, provide a record of the business lunch activity at the company.
Key forms
This section lists the major forms associated with the Lunch Scheduler application.
Note: You must run arjoinfix (UNIX) or ARJOINFIX.EXE (Windows) on all forms you create for use with the Approval Server. This executable modifies the join qualifications to make sure your applications communicate properly with the Approval Server when you have more than one application requiring approvals.
AP-Sample:Lunch Scheduler This is the base form of the application. It is the form that the lunch requests are entered into and the form that approvals are tied to. AP-Sample:Lunch-Detail This is the inner join between the AP-Sample:Lunch Scheduler and the AP:Detail forms. This inner join is used for internal processing within the Approval Server and for Global Override operations. The join criteria is Request ID to Request.
Key forms
215
AP-Sample:Lunch-Detail-Signatu This is the inner join between the AP-Sample:Lunch Scheduler and the AP:Detail-Signature forms. This is the main working form for approvers who are approving lunch requests. The join criteria is Request ID to Request. AP-Sample:Company This is a supporting form where companies and information about them is entered. The data here drives menus and settings about the companies. AP-Sample:Restaurant This is a supporting form where restaurants and information about them is entered. The data here drives menus and settings about the restaurants. AP-Sample:Signature Authority This is a supporting form where approvers and information about them is entered. Information about managers is used to drive advancement along the management chain. Information about their signature authority determines when someone has sufficient authority to be the last person needing to sign. Account Approval Level indicates whether someone is on the major or enterprise account team and involved in the second stage approval process.
The tag argument identifies the process to run. See New-Details on page 261 for more information about this Approval Server command.
217
The Account Overdue check box on the AP-Sample:Company form determines if the account is overdue. The Special Overdue Approval process is launched by the filter APSample:Start Overdue Approv. The Run If filter criteria must be met for this filter to execute.
Previewing approvers
You can use the AP:PreviewInfo vendor form to view the completed and remaining approvals. The AP:PreviewInfo form takes the Process Name, Request ID, and Retrieval Type as input values. There are three retrieval types: FullShows completed and future approvals. RemainingShows only pending approvals. CompletedShows only approval requests which are already approved. As shown in Figure 12-2, the preview list includes the status of the signatures. Finally, you can configure the approval process to view past, current, and future approvals.
Figure 12-2: Preview information list
You can also create a display-only form that displays the preview information and executes the parameterized rules. The following example gives you a glimpse of the parameterized rules and approval preview in use.
Note: You cannot create a private server queue unless your server is licensed.
Remember the RPC program number you entered. You use it in the ar.cfg or ar.conf file.
3 Open the ar.cfg or ar.conf file in a text editor. 4 Add the following line to the file and save your changes.
Plugin-Loopback-RPC-Socket: <RPC_program_number> Approval-RPC-Socket: <RPC_program_number>
5 Stop and then restart the AR System server. 6 In BMC Remedy User, open the AP:Administration form. 7 Refresh the Process table field to see all available processes, as shown in
Figure 12-3.
Figure 12-3: Available processes
8 Click View to open one of the processes that are attached to the AP-
Sample:Lunch Scheduler form, for example, Major Account Level Approval. The Process Definition form opens.
9 In the Generate Preview field, select one of the options, for example, On
Generation or Change to a Signature.
219
10 Save your changes. 11 On a front-end form that you want to use to view approvers, create a table
field that queries the AP:PreviewInfo form. For example, Figure 12-4 illustrates a form that queries entries that require approvals in the AP-Sample:Lunch Scheduler form.
Figure 12-4: Parameterized Rule Test form
If you click an entry that is pending approval, the entry is opened in the AP:Signature form. Approvers can accept or reject the approval as needed.
12 (Optional) You can create filter workflow which fires the following
Add-PGNA-Values command:
Application-Command Approval Add-PGNA-Values -t "$Signature ID add$" -o $Rule Name$ -l "$Short Description$"
This command executes the Parameterized Get Next Approver rule type so that you can add additional approvers ad hoc as needed.
13 Open the AP-Sample:Lunch Scheduler form in New mode and create a
this note launches the testing for the second process, Major Account Level Approval. Approval Process Done rules are used to populate this Approval Workspace field.
Step 3 If the customer is a major or enterprise account, the Major Account Level
field. Writing this note launches the testing for the third process, Special Overdue Approval. Approval Process Done rules are used to populate this Approval Workspace field.
221
Step 5 If the account is overdue, the Special Overdue Approval process runs.
Using the Approval Workspace field, the system knows which process is active and in progress, and can monitor the flow across three approval processes.
Note: The Approval Workspace field is updated with a setting to indicate success of the Major Account Level Approval process even when there is no action to be taken on the level process. It is important that the process be marked successful in this case, so that the test for the next process can simply be for approved or not approved, without having to worry about how it got to the approved state.
Special techniques
This section introduces techniques that you might want to use in your own approval processes. These techniques include: More information on page 223 Show summary and signatures on page 224 Show password field if required on page 225 They detail how you can add a little more than the minimum needed to link your application to the Approval Server, and get a richer integration with additional capabilities for your users.
More information
It is useful to review all information for a request from one place. The APSample:Lunch-Detail-Signatu form has a button named Manage More Information. This button takes you to a dialog box that allows you to review and respond to (if appropriate) the More Information Requests on the current record. This button links to a dialog box that provides a list of all More Information records for the current request. You can review all requests and their current state. Use BMC Remedy Administrator to review the button Manage More Information about the AP-Sample:Lunch-Detail-Signatu form. Also review the active links AP-Sample-Dtl-Sig:MoreInfo01 through AP-Sample-DtlSig:MoreInfo06. To take advantage of this extension in your own approval forms, follow this procedure.
through AP-Sample-Dtl-Sig:MoreInfo06.
4 For each copy, change the attached form to your xxx-DetailSignature join
form.
Special techniques 223
BMC Remedy Approval Server Figure 12-5: Copy AP-Sample-Dtl-Sig: MoreInfo01 through MoreInfo06
AP-Sample:DisableShowOnCreate AP-Sample:Show App Signatures AP-Sample:Show App Summary For each copy, change the attached form to your xxx-join form.
3 Export the three active links and edit them to match your application: a Substitute your database IDs for the two buttons. b Substitute the names of your Detail and Detail Signature forms for the Set-
AP-Sample:ShowPwdIfRequired1 AP-Sample:ShowPwdIfRequired2
3 For each copy, change the form to which they are attached to your xxx-Detail
Special techniques
225
Sample users
The Approval Server samples include records for a number of imaginary users preconfigured for testing the Lunch Scheduler application.
Note: The procedures in Chapter 6, Using a sample application, require sample users Frank Williams, Jack Miller, Larry Goldstein, Violet Anderson, and Sue Smith to be licensed AR System login names.
Sample users
227
Chapter
13
229
secondary form.
Important: New functionality was added to the AP:Detail form to enable workflow-based notifications. For more information, see Enabling workflow-based notifications on page 235.
This join form is used only for internal processing so the appearance of the form is not critical.
a Join Request ID (field ID 1) of your form xxx to the Request field (field ID
8) of form AP:Detail.
b Include all fields from xxx form and all fields from AP:Detail. c Keep the default views with the join.
Before you save your join form, you must manually specify a reserved ID for two fields, as described in step a and step b. Use the Find Field feature in BMC Remedy Administrator to more easily locate and open these fields.
a Open the Status-Dtl field ID 7 from AP:Detail. On the Display tab, change
the field access to Read/Write to enable global overrides. Click the Database tab. Type the number 13191 in the empty ID field.
b Open the Request field ID 8 from AP:Detail. Click the Database tab. Type
Make sure Public appears in the Permissions field. Assign Public the Hidden characteristic. Without this step, the approvers cannot use APW:Approval Central properly. Before you save your join form, you must manually specify a reserved ID for two fields, as described in step a and step b.
a Save your join form. b Click OK both times when the AR System asks you to confirm your
intention to use reserved IDs. You can also ignore any subsequent warnings.
3 In BMC Remedy Administrator, verify xxx (your primary application form)
has permissions set as shown in the following table. This allows approvers to change the fields. Otherwise, the fields listed in the table can be modified only by the AR System administrator.
DB ID 1 2 3 4 5 6 Default label Request ID Submitter Create Date Assigned To Last Modified By Permissions Assignee (view) Public (view) Assignee (view) Public (view) Assignee (view) Public (view) Assignee (change) Public (view) Assignee (view) N/A N/A Yes $USER$ N/A Yes $USER$ Allow any user Default value to submit N/A No
231
DB ID 7
Short Description
Yes
4 Create an inner join between xxx and AP:Detail-Signature, with xxx as the
This form is where your users will spend much of their time when reviewing approvals, so attention to the layout and appearance of the form is important. You might hide or remove from view most of the fields of the AP:Detail-Signature form. Use tabs in a page field to display only those fields that are significant or that you want your users to have access to.
Tip: When selecting a field, use the Find Field feature in BMC Remedy Administrator to more easily locate it. Then choose Layout > Bring to Front to select the field.
Move the Approval Status field (ID 13191) from the AP:DetailSignature form to a prominent location, because this is the field approvers use to approve or reject a request. Move the Status field ID 7 from your form xxx to a subordinate position, because within the approval environment the Status of your application xxx is not as important as the Status of the approval request.
d Choose Form Menu > Form Properties > Permissions tab.
Make sure Public appears in the Permissions field. Assign Public the Hidden characteristic. Without this step, the approvers cannot use APW:Approval Central properly.
While creating the join, you might receive several notes about a field being accessible only to the Administrator. Click OK to continue. This message is a warning that there are no extra permissions on several fields. These fields are used strictly by workflow and are related to the security of the approval process. They do not indicate that something is wrong. You will not receive these messages if you have configured AR System Administrator to suppress this warning.
5 Once the joins are created, run the program arjoinfix (UNIX) or
Find this program in the same directory as the BMC Remedy Approval Server program.
Note: You must run arjoinfix (UNIX) or arjoinfix.exe (Windows) on all forms you create for use with the Approval Server. This executable modifies the join qualifications to make sure your applications communicate properly with the Approval Server when you have more than one application requiring approvals.
This program prompts you for the name of the form that you are linking to the Approval Server, xxx in this example. It will then find the two joins that you have created and update the join criteria to include the form name. If you do not have Registered with Port Mapper enabled in their environment or you do not even want to temporarily enable this option on your AR System server, you can use the following option that can be passed to the arjoinfix utility from the command or shell line:
arjoinfix -portnum <number>
Finally, UNIX/Solaris users must use the following command option to avoid password problems: arjoinfix -i <install_dir>
233
6 Launch BMC Remedy User. On form AP:Administration, click the Form tab
and create an entry for xxx, the form in your application that launches the approval process. This registers and connects your application with the Approval Server so that the AR System can process approvals appropriately with your applications workflow. To perform this step, you must be a Process Administrator with Full Admin authority for all processes (or an AR System Administrator). Enter a keyword in the Lookup Keyword field to enable easy identification when searching for this form.
7 Design your approval process. This is a paper and pencil stage, not to be
confused with implementation using the AR System. This stage is vital to the success of your approval-based application. If you have a thorough understanding of your approval process, you will be rewarded with a smooth implementation.
8 Implement your definitions within the AR System. Here you create the
Notifications, Processes, Rules, and Roles to handle all approval processes you planned in the previous step. For more information, see the following sections: See Using approval notifications on page 127 for creating notifications. See Defining an approval process on page 139 for creating processes. See Defining approval rules on page 153 for creating rules. See Managing users and roles on page 207 for creating roles.
9 Connect your application form xxx to the Approval Server with at least one
filter to start the approval process. The filter should run the Approval Server New-Details command to initiate the approval process. You might find that you go back and forth between this step and the previous before your workflow is smooth and presentable. For example, to start the approval process, you would create a filter that has a Run Process action. This action would issue the command to the Approval Server to initiate approval processing for the current entry. Here is an example command starting a process named ABC:
Application-Command Approval New-Details -s $SCHEMA$ -e $Request ID$ -t ABC
See Appendix B, Application commands, for details on Approval Server commands and Overview of the Lunch Scheduler application on page 214 for the filters used to create a chained approval process.
reported to form xxx. This is very important. For more information, see Working with Approval Process Done rules on page 201. Optionally, you can add links to stop a pending process or to provide more information.
11 To chain approvals together, repeat step 8 through step 10 as many times as
needed.
a Define the workflow needed to start an approval process using the
Process Done rules. For more information, including examples, see Chaining approval processes on page 221.
12 If you chain together more than one process, add a field to your form xxx to
display its status. For example, an application can display where a request is within three chained processes in which management approves the need, then MIS approves a model, and finally the corporate buyer must approve a vendor.
235
join: Notification Message (field ID 12303) Subject (field ID 12305) Additional Fields (field ID 12340) Process Instance ID (field ID 13201)
3 In the AP:Notification form, follow the steps to create a notification for your
actions:
a Create a Set Fields action that pushes the values from the AP:Notification
form used for message details to the display-only fields that you added to the AP:Details form. For example, define the Set Fields action to push the value from the Subject field on AP:Notification to the Subject display-only field on AP:Details.
b Create a Call Guide action that selects the AP:Workflow Notifications
Guide. The Approval Server installation program adds this filter to the server.
7 Add your filter to the AP:Workflow Notifications Guide filter guide.
This filter guide was created in the 7.0 release for use with workflow-based notifications. This filter guide provides application designers a mechanism to write your own workflow-based notifications which retrieve your notification events from the Approval Server. When the approval cycle event triggers the notification, the Approval Server fires a filter that sends the notification.
For example, if you are creating a web view, arrange the fields the way you like them.
3 For web views, create a results list field and make it hidden.
This field is needed so that users can drill down to look at individual approval records from the Approval Central view. Users will not interact with it, so it should be hidden.
4 Create a Save Changes button and an active link that pushes the values to
your join form. The easiest way to do this is to copy the button from the AP-Sample:Lunch-Detail-Signatu form, then copy the AP-Lunch-Dtl-Sig:SaveChanges active link and modify its actions to operate against your application.
237
5 Open the appropriate view of the APW:Approval Central form and create a
table field that displays records from your join form. The table should have the same features as those that already exist for the two sample applications, so the best way to do this is to copy and paste one of those tables and then modify it.
a Make sure that a column in the table points to the request ID field
(field ID 1) of your form, and that the column gives View permission to the Public group. You can hide this column.
b For web views, make sure that the Web Drill Down Column is not one of
the first three columns, which display as radio buttons. A column pointing to a request ID field is a good choice.
c Use the field name of your request ID column in the HTML radio button
code in the Default Value of the first three columns in the table.
links and replace the LS in their names to something denoting your application. Change their actions to operate against your application instead of the Lunch Scheduler sample application.
3 Create an active link guide that loops these two active links in numerical
guide and another action to refresh the table field for your application in
APW:Approval Central.
buttons) from the web view of a sample application form to your join form. Be sure to keep the same names and field IDs.
2 Add your form to the list of forms for the APW:GoAccessPriv,
APW:GoMoreInfo, and APW:logout active links.
239
Appendix
Worksheets
The worksheets in this appendix are intended to assist you in designing the various components of the 7.0 Approval Server. Reproduce the worksheets as needed. The following topics are provided: Process worksheets (page 242) Rule worksheets (page 245)
Worksheets
241
Process worksheets
The following process worksheets help you set up your process and escalations. Defining a process on page 242 More information escalations on page 242 Signature escalations on page 243
Defining a process
Use this worksheet to help you design a process.
Process Name Form Process Type Request Owner Field First Approver Field Approval Success If Multiple Approvers Allow Ad Hoc Next Approver? For Self Assignment Validate Approvers? Require Password? No more approvals One Must Sign Anyone Use Get Next Approver Rules Yes Yes Completion rule All Must Sign Approver Assign to Owner If Approver No No Allow Only One Approver No one Always Assign to Owner
Signature escalations
Use the following worksheets to help you set the Notification parameters on the Process form.
Process worksheets
243
Notification: Still Outstanding First Interval Repeat Interval Notification: Still in StatePending First Interval Repeat Interval Notification: Still in StateError First Interval Repeat Interval Notification: Still in StateHold First Interval Repeat Interval Notification: Still in StateMore Information First Interval Repeat Interval Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit
Notification: Still in StateMore Information First Interval Repeat Interval Unit Unit
Rule worksheets
Use the following worksheets to help set up your rules. Auto-Approval rules on page 245 Get Authority Self rules on page 246 Get Authority rules on page 246 Self-Approval rules on page 247 Validate Approver rules on page 247 Prep Get Next Approver rules on page 248 Get Next Approver rules on page 249 Get Authority Regular rules on page 250 Completion rules on page 250 Parameterized Get Next Approver rules on page 251 Signature Accumulator Done rules on page 252 Statistical Override Done rules on page 252 Approval Process Done rules on page 253
Auto-Approval rules
Rule Name Purpose For Process Rule Audit Text
Rule worksheets
245
Self-Approval rules
Rule Name Purpose For Process Rule Audit Text
Rule worksheets
247
o Ending
Rule worksheets
249
Completion rules
Rule Name Purpose For Process Rule
o Ending
Rule worksheets
251
o Query
o SQL
Rule worksheets
253
Appendix
Application commands
To support close interaction between the AR System server and the Approval Server, you use a special process, Application-Command. This process can be run from filters, escalations, and active links using the Run Process action. The following topics are provided: Basic information (page 256) Specific Approval Server commands (page 258)
Application commands
255
Basic information
The Application-Command process allows the specification of commands to be executed by an application. A special form named Application Pending is automatically created and managed by the AR System server. Whenever the Application-Command process is run, a request is created in this form with details about the command issued. the Approval Server process retrieves commands from this form for processing. This process uses the Run Process action. Although no actual process is run, it follows all the rules and restrictions of a process. This means that you must be sure to quote parameters with spaces just like you would for a traditional process. In addition, it is a process that exists on the server. So, if you are performing an operation from an active link, you must be sure to use the syntax that indicates that the process should be run as a remote process on the server (versus on the client). The basic command format is:
Application-Command category command [-s form] [-e request-id] [-t tag] [-1 field-1] [-2 field-2] [-3 field-3] [-o other-string-<-255] [-l other-string-unlimited]
The category and command parameters are positional. The other parameters are optional and can appear in any order after the two positional parameters. This list describes the parameters in greater detail: categoryA character string with a maximum of 30 characters that identifies which application the command is for. For the Approval Server, this value is always Approval. commandA character string with a maximum of 30 characters that indicates a specific operation to be performed within the category. Commands for the Approval Server are defined in the next section. formThe name of a form that the command is related to. If no form is specified, this value defaults to the form the filter or active link is attached to. request-idThe ID of the request that the command is related to. If the request is a join form, the request ID string consists of the ID of each request separated by a vertical bar, such as: 000000000012344|000000000084934. If no request ID is specified, this value defaults to the current entry ID.
tagA tag that is specific to the category and command. This might be a further identifier for the operation. For example, for many approval commands, the tag is the name of the approval process. field-1The ID of a field or an integer code associated with the category or command. field-2The ID of a field or an integer code associated with the category or command. field-3The ID of a field or an integer code associated with the category or command. other-string-<-255A string with a maximum of 255 characters. other-string-unlimitedA string with no maximum. For the form and request-id arguments, the -s and -e parameters default to the current form and current request ID if the operation is performed from a filter or escalation. Therefore, if the default values are sufficient, the -s and -e parameters can be omitted. If the operation is performed from an active link, the AR System server cannot determine what the current environment is, and these values must be supplied. As a general rule, any parameter you supply that is not defined for the command is ignored. Extra parameters will not cause a failure, but they will also not affect the running of the command. Avoid supplying extra parameters. Example command This command would start the approval process named MyProcess against the current entry:
Application-Command Approval New-Details -s $SCHEMA$ -e $Request-ID -t MyProcess
Notice the quotes around the arguments. You should always use quotes around arguments to insure that they are processed correctly when they contain spaces.
Basic information
257
information.
Add-Sig
Add-Sig [-s form] [-e request-id] [-t process-name] {-o approverlist} [-1 {0|1}] [-2 {0|1|2|999}] [-l Assignee Group ID]
This command adds an additional signature line to an existing approval request (or creates a new approval request if there is not one) for the specified request. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, the specified approval process is activated. If it is not supplied, the system searches for a process against the specified form. If there is only one process specified, that process is used. If several processes are specified, an error is reported, and no approval process starts. The approver-list argument contains the approvers to add. If omitted, this command performs no work. Multiple approvers are separated by a semicolon. The 1 option indicates whether the new signature line is identified as independent Yes or independent No, based on whether the value is set to 1 (no) or some other value (yes). The 2 option indicates the action to take on multiple approvers. 0 (the default) means one of, 1 means all of, 2 means only one, and 999 means to pull the value from the process definition. The -l optional parameter was added to allow you to pass in a value for field 112 (Assignee Group Permissions) for the multitenancy feature.
The operation of this command generally links to an existing approval details record, although it creates one if none exists. It then adds one or more signature lines for the value specified in the other option.
Add-PGNA-Values
Add-PGNA-Values [-t detail-id] [-o rule-name] [-l values-list]
This command is used by the application to provide the variable values for the Parameterized Get Next Approver rule type. The following format for this signal will is used: The detail-id parameter is the request ID of the AP:Detail record. The rule-name parameter is the name of the Get Next Approver rule these values are meant for. The values-list parameter is the list of values. The following example provides a sample signal you can create:
Add-PGNA-GNA-values -t "00000000000012" -o "Sample Param GNA Rule" -l "4/Frank Williams"
Det-Approved
Det-Approved [-s form] [-e request-id] [-t process-name]
This command marks the approval detail item Approved. Any outstanding signature lines or More Information records are marked Closed. The Process Done phase notifies the associated request of the approval. This command corresponds to an approval by global override. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
Det-Cancelled
Det-Cancelled [-s form] [-e request-id] [-t process-name]
259
This command stops an approval process that is in progress, marking the approval detail item Cancelled. Any outstanding signature lines or More Information records are marked Cancelled. The Process Done phase notifies the associated request of the cancellation. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
Det-Error
Det-Error [-s form] [-e request-id] [-t process-name]
This command marks the approval detail item to be in error. Any outstanding signature lines or More Information records are marked Closed. The Process Done phase notifies the associated request of the error. This command is intended only to be used internally by Approval Server. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
Det-Rejected
Det-Rejected [-s form] [-e request-id] [-t process-name]
This command marks the approval detail item Rejected. Any outstanding signature lines or More Information records are marked Closed. The Process Done phase notifies the associated request of the rejection. This command corresponds to a rejection by global override. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
MoreInfo-Return
MoreInfo-Return [-s form] [-e request-id]
This command takes data from the specified More Information request and copies the response back to the associated signature request. The More Information request identified must be marked Completed. The form parameter is optional. If it is supplied, it must be the More Information form. The request-id parameter is optional. The request-id parameter is the ID of the More Information record.
New-Details
New-Details [-s form] [-e request-id] [-t process-name] [-1 priority] [-l Assignee Group ID]
This command starts the Approval Server process for the specified request. The form and request to be approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, the specified approval process is activated. If it is not supplied, the system searches for a process against the specified form. If there is only one process specified, that process is used. If several processes are specified, an error is reported, and no approval process starts. The priority parameter is also optional. If they are supplied, it sets the priority to Urgent (1), Normal (2), or Low (3). Any other setting is ignored, and the defaultNormal (2)is applied. The -l optional parameter was added to allow you to pass in a value for field 112 (Assignee Group Permissions) for the multitenancy feature. The operation of this command creates an approval details record. It then searches for auto- and self-approval rules; if one of them passes, it marks the record Approved and continues with the Process Done phase to update the associated request. If no auto- or self-approval rules pass, the first set of approvers is found and signature lines are created for them as defined by the rules of the system.
261
Rename-Form
Rename-Form {-t old-name} {-o new-name} [-1 only-active] [-2 dorename]
This command changes the name of a form. All references in the definition forms are updated. If the only-active parameter is set to 1, only active entries are updated. Any other setting causes all entries to be updated. This setting controls which AP:Detail records are updated. All definition records are always updated. If the do-rename parameter is set to 1, the form itself is renamed. Any other setting assumes the form has already been renamed by using the AR System Administrator tool and you are simply updating cross-references.
Rename-Process
Rename-Process {-t old-name} {-o new-name} [-1 only-active] [-2 do-rename]
This command changes the name of a process. All references in definition forms are updated. The name of a process can be as long as 80 bytes. This equates to 80 characters in English and most European languages, but only 40 characters in double-byte languages. If the only-active parameter is set to 1, only active entries are updated. Any other setting causes all entries to be updated. This setting controls which AP:Detail records are updated. All definition records are always updated. If the do-rename parameter is set to 1, the process itself is renamed. Any other setting assumes the process has already been renamed by using the AP:Process form and you are simply updating cross-references.
Sig-Approved
Sig-Approved [-s form] [-e request-id] [-t process-name]
This command performs approval processing on a signature line that has been marked Approved. The rule process continues to the next approvers. This command is issued when a signature line is changed to Approved. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of the signature entry and is also optional.
The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Sig-Cancelled
Sig-Cancelled [-s form] [-e request-id] [-t process-name]
This command performs cancellation processing on a signature line that has been marked Cancelled. The request can be in any active state (Pending, Hold, More Information) for this operation to be performed. The signature line is cancelled and appropriate moves within the process are performed, depending on whether other signature lines are active. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of the signature entry and is also optional. The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Sig-Notify
Sig-Notify [-s form] [-e request-id] [-1 num-notifies]
This command causes a notification message to be sent, indicating that the specified AP:Signature record has exceeded its defined time limit without being resolved. The notification message is sent to the corresponding formAP:Detail-Signature join. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of an AP:Signature form request and is also optional. The num-notifies parameter indicates that this is the initial notification for a value of 0 (the default) or that this is a repeat notification for any other value. This triggers delivery of the notification or repeat notification message.
263
Sig-Notify-Change
Sig-Notify-Change [-s form] [-e request-id]
This command causes a notification message to be sent, indicating that the specified entry has been changed. The notification is sent to any approvers who have previously approved the process that is indicated. The notification is informational, to let previous approvers know of a change. The notification message is sent to the corresponding form-AP:Detail-Signature join. The form and request-id parameters in this command are optional. If supplied, they identify the entry that is to be notified, for example, if you want to create an approval notification from a form in the Change Management application. The process-name parameter is optional. If supplied, only the approved signatures tied to the process specified are notified. If not supplied, all approved signatures for all processes associated with the record are notified.
Sig-Notify-State
Sig-Notify-State [-s form] [-e request-id] [-1 num-notifies] {-2 state} [-3 0|1]
This command causes a notification message to be sent, indicating that the specified AP:Signature record has exceeded its defined time limit for a given state without being resolved. The notification message is sent to the corresponding form-AP:Detail-Signature join. The form parameter is optional. If supplied, it must be the AP:Signature form. The num-notifies parameter indicates that this is the initial notification for a value of 0 (the default) or that this is a repeat notification for any other value. This triggers delivery of the notification or repeat notification message. The state parameter is the numeric value for the state the notification is for. It can be set to 0 (Pending), 3 (Hold), 4 (More Information), or 6 (Error). Any other setting will default to 0 (Pending). Set the 3 parameter to 0 (the default) to indicate the notification is for an escalation or 1 to indicate that the notification is simply a direct notification. Any other value assumes the default.
Sig-Reassign
Sig-Reassign [-s form] [-e request-id] [-t process-name] {-o short-list | -l long-list}
This command reassigns the signature line to another approver list by using either the -o (for an approver list less than 255 characters) or -l option. The signature line must be in an active state (Pending, Hold, or More Information) for this operation to be performed. The form parameter is optional. If supplied, it must be the AP:Signature form. The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Sig-Rejected
Sig-Rejected [-s form] [-e request-id] [-t process-name]
This command performs the rejection processing on a signature line that has been marked Rejected. The process of marking the associated detail line Rejected is performed. This command is issued when a signature line is changed to Rejected. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of the signature entry and is also optional. The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Update-Config
Update-Config {-t label} [-o value]
This command updates the administrative configuration settings for the application. The specific setting being updated is identified by the label parameter. This label is defined in arstruct.h and is placed in the ar.cfg (ar.conf) file.
265
The value parameter can be omitted to cause the setting to be reset to its default value or to a value in the appropriate format for the ar.cfg (ar.conf) file. The Approval Server reacts immediately to changes in settings that are not start-up-only. For the approval notification option, no value resets all options to their default value. Otherwise, only the option that is defined in the value parameter is reset. For the debug mode, other debug options can be defined and, if they are, this setting takes effect. However, if only a 0 or 65536 (the setting for approval debugging) are set, only that flag is changed, and other settings remain as they are in the file.
Appendix
Approval forms
This appendix displays all the 7.0 Approval Server forms and provides field descriptions. The 7.0 release made it easier for administrators and users to access the most important approval server functionality in the Approval Central and Administration forms. For example, the best practice now is to use AP:Administration to access the Server Settings and Rename settings and not open the helper forms independently.
Approval forms
267
Use the menu list to select a status for a search. Leave the field empty to view all your approvals. Enter the name of the next approver. This must be an AR System login ID.
AP:Administration
Process administrators use this form as a launch pad to create and modify records that make up approval processes. For more information, see Using the Approval Server Administration form on page 118.
Figure C-2: Administration form
Show for process Use the menu list to limit the display list to items associated with the selected process. This field is not active for the Role and Form categories. Click a tab to display a list of items of that type. This also selects Process, rule, notification, role, which category of items is involved when you click the buttons on this form. form, administrator, alternate View Search Create Delete Click this button to open the item selected. Click this button to open a search form for items of the category determined by the current tab. Click this button to create a new item of the category determined by the current tab. Click this button to discard the currently selected item. It opens the form that appears in AP:Admin-DeleteVerify on page 270.
AP:Administration
269
Click this button to have the AR System reload the displayed list. Click this link in the navigation pane to open the Server Settings form. For more information, see AP:AdminServerSettings on page 272. Click this link in the navigation pane to open the form that appears in AP:Admin-Rename on page 271 to rename the currently selected item.
Rename
AP:Admin-DeleteVerify
This dialog box appears when a process administrator clicks the Delete button on the AP:Administrator form.
Figure C-3: AP:Admin-DeleteVerify dialog box form
No Yes
Click this button to close the form with no action performed. Click this button to delete the item selected in the previous form.
AP:Admin-Rename
This dialog box appears when a process administrator selects Rename in the navigation pane of the Administration form.
Figure C-4: AP:Admin-Rename dialog box
Use the menu list to determine whether this rename operation is performed on a form or a process. Type a name or use the menu list to select an item to be renamed. Type the replacement name for the item in the From Old Name field, or use the menu list to select a name. The name of a process can be as long as 80 bytes. This equates to 80 characters in English and most European languages, but only 40 characters in double-byte languages.
Update
Select an option from the drop-down menu to determine which of the associated detail records are renamed. All renames detail records for current and past approval requests. Only Active Objects renames detail records only for currently open approval requests.
Select this check box to include the form or process you are renaming. This is useful if you are renaming all references to the name of an item that has been manually renamed previously.
Rename Cancel
Click this button to complete this rename operation. Click this button to close the form with no action performed.
AP:Administration
271
Note: If you renamed a process manually instead of using the Rename dialog box, the Rename command will not change names of attached rules. You must restore the process name manually and then rename the entire process. Or you can rename all the attached rules using the Rename dialog box.
AP:Admin-ServerSettings
Process administrators use this form to change server settings regarding the Approval Server. To open this form, select Server Settings in the navigation pane in the AP:Administrator form.
Basic tab
Figure C-5: AP:Admin-ServerSettings formBasic tab
Select this check box to enable the Debug mode, which creates entries in the log file. Type the directory path and file name in which to store log entries for the Debug mode.
Type a number of seconds in this field to determine how often Approval Server checks the definitions for changes. A larger number increases AR System performance by checking less often. A smaller number of seconds is useful while creating and testing a process. A zero (0) in this field causes the system to check for definition changes with each operation.
Private AR server Type the RPC socket number of a dedicated private server to RPC socket use when accessing the AR System server. Leave this field empty if you do not have a dedicated private server. Virtual web document directory Save Reset Cancel Type the path for the directory where Approval Web forms are stored. Click this button to apply changes. Click this button to reload the form with previously stored values. Click this button to close the dialog box without saving changes.
AP:Administration
273
Notifications tab
Figure C-6: AP:Admin-ServerSettings formNotifications tab
New signature, approve, reject, alternate approve, alternate reject, override approve, override reject, close approve, close reject, reassign, error, cancel, more info return, reject by later level, cancel at later level, reject by another approver, hold, more info, change after approval
On the Notifications tab, click Enabled next to an event to have the AR System issue a notification when such an event occurs. Disabled means Approval Server disables notifications for this event during an approval process. Enabled means the Approval Server enables notifications for the approver list when this event occurs during an approval process. Enabled Including Alternate (default setting) means the Approval Server enables notifications to the approver list as well as all active alternates when this event occurs during an approval process. These option buttons do not guarantee notifications occur for an enabled event. These settings enable notification as established elsewhere in the process rules.
Escalations tab
Figure C-7: AP:Admin-ServerSettings formEscalations tab
On the Escalation tab, click Enabled next to an event to have Still active, still the AR System issue an escalation when such an event occurs. active (repeat), still pending, still Disabled means Approval Server disables escalations for this pending (repeat), event during an approval process. still hold, still Enabled means the Approval Server enables escalations for hold (repeat), still the approver list when this event occurs during an approval more info, still process. more info Enabled Including Alternate (default setting) means the (repeat), still Approval Server enables escalations to the approver list as error, still error well all active alternates when this event occurs during an (repeat) approval process. These option buttons do not guarantee escalations occur for an enabled event. These settings enable escalations as established elsewhere in the process rules.
AP:Administration
275
AP:Alternate
Approvers use this form to create, delete, and maintain alternate approvers.
Type the name of the individual who is to receive the approval privileges. Type the name of the person for whom the Alternate will substitute. Open the calendar control to select the date on which the alternates authority begins. Open the calendar control to select the date on which the alternates authority ends.
Notify alternate
Use the menu list to select whether the alternate is notified when a request comes to the original approver. Yes notifies the alternate when a request is pending. No does not notify the alternate. To notify alternates, the process administrator must do the following tasks:
1 Create notifications on the New Signature notify on event. 2 Select Enabled Including Alternative on the Server Settings
form. Covering Select a value from this menu list to determine which processes are included in this alternates authority. All specifies that this alternate has authority to approve all processes where the original approver has authority. Specific Process specifies that this alternate has authority over only processes specifically noted in the Process field following. Process Enter the process for which the alternate has authority. Use the menu list to make sure you select only a process that exists on this server. This field contains the status of the alternate: Future means this alternate is not yet active. Current means the alternate is presently active. Past means the alternate is no longer active. Cancelled means the alternate record has been cancelled and the alternate is not active. Search Save Close In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
Status
AP:Administration
277
The AR System populates this field with an AR System ID for this record. The AR System populates this field with the date this alternate was created. Type the name of the original approver assigning authority to this alternate. Type information to aid users who are setting up alternates. Type any additional information to be recorded with the alternate assignment. This information becomes part of the permanent record for this alternate.
Last modified by The AR System populates this field with the name of the person who last modified this alternate. Modified date The AR System populates this field with the date of the last modification to this alternate.
AP:Detail
Process administrators use this form to track and override approval requests. In addition to the fields listed below, the AP:Detail form also includes Currency, Date and Time temporary fields for use in workflow to store intermediate results. For example, Currency Field 1 and Currency Field 2 are temporary fields of the currency type.
Important: New functionality was added to the AP:Detail form to enable workflow-based notifications.
Figure C-10: AP:Detail form
The AR System populates this field the name of the AR System application to be approved with this request. The AR System populates this field with the AR System ID for the request. The AR System populates this field with the name of the approval process of this request. Type any additional information to be recorded with the alternate assignment. This information becomes part of the permanent record for this request. Use the menu list to select the priority attached to this request. Each process defines the meaning behind Urgent, Normal, and Low. The AR System populates this field with the name of the person who requested the workflow to be approved. The AR System populates this field with the status of the request.
Priority
Submitter Status
AP:Administration
279
Approval audit
This field contains an audit trail of date, time, and approver when approval activity occurs to this request. This information becomes part of the permanent record for this request. Click this button to approve the request, overriding the regular approval process. You must have process administrator override authority to perform this action. Click this button to reject the request, overriding the regular approval process. You must have process administrator override authority to perform this action.
Global approve
Global reject
AP:Detail-Signature
Process Administrators use this form to track the history of responses to an approval request. In addition to the following fields listed, the AP:DetailSignature form also includes Currency, Date and Time temporary fields for you to use in workflow to store intermediate results. For example, Currency Field 1 and Currency Field 2 are temporary fields of the currency type.
Approval status
Use the menu list to select the status of the request. Pending means the Approval Server is waiting for a response to a request in progress. Approved means you approve the workflow associated with this request. Rejected means you do not allow the workflow to be approved, cancelling the request entirely. Hold means you are associated with this request but no Approval Server actions occur. More Information means you are waiting for a response to a More Information Request you submitted to supply you with more information before you can approve or reject this request. Cancelled means this request was withdrawn from the approval process. Error means this request has a problem that needs to be repaired before additional operations can be performed. Closed means this request is ended and operations can no longer be performed on it. Type your password for verification. the Approval Server verifies the contents of this field before a Save operation occurs. This field occurs only during Search and Modify, not when the record is created.
Password
AP:Administration
281
Use the menu list to select the priority attached to this request. Each process defines the meaning behind Urgent, Normal, and Low. Type any additional information to be recorded with the alternate assignment. This information becomes part of the permanent record for this alternate. Type the names of the next approvers to see this request. Select how the approval process operates when many approvers appear in the Next Approver field. One must sign determines that only one signature is required from everyone indicated in the Next Approver field. All must sign determines that everyone indicated in the Next Approver field must approve the request. This option button is valid only if there is more than one entry in the Next Approver field.
Reassign to Approvers Approval audit For application For request For process Submitter Approver signature Alternate signature
Type the name of an approver to whom you want to reassign this request. The AR System populates this field with the names of persons who have already approved this request. This field contains an audit trail of date, time, and approver when approval activity occurs to this request. This information becomes part of the permanent record for this request. The AR System populates this field with the name of the AR System application workflow to be approved with this request. The AR System populates this field with the AR System ID for the request. The AR System populates this field with the name of the approval process of this request. The AR System populates this field with the name of the person who originated this request. This field contains the name of the approver of this request. The name appears only after an authorized person modifies the Approval Status field. This field contains the name of the alternate approver who modifies the Approval Status field.
This field contains any requests for more information and the responses when they occur to this request. This information becomes part of the permanent record for this request. Click this button to open the form for the workflow the requester wants to be approved. Click this button to open the More Information form with which you can request additional information.
AP:Dtl-Sig-MoreInfoDialog
This underlying helper form is used to process the More Information records. You should access this information only through the Approval Central application.
Figure C-12: AP:Dtl-Sig-MoreInfoDialog form
This field displays any More Information records attached to the current approval process. Use this button to open the More Information form and create a new More Information record. Click this button to open the currently selected item in the field preceding. Click this button to close the form.
AP:Administration
283
AP:Form
Process Administrators use this form to attach request forms to an Approval Server process.
Figure C-13: AP:form, Form tab
Form name
Type a form name or use the menu list to select a form on the current server.
Lookup keyword Type a keyword to enable easy identification when searching for this form. Used by Approval reporting Type the name of the AR System application that uses the form. Type the name of a form or use the menu list to select a form that users might search using the Application Approval Search button described on Approval Central application on page 268. Approval Reporting is an optional field. Search Save Close In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:More information
This underlying helper form is used to process the questions about an approval request. You should access this information only through the Approval Central application.
Figure C-14: AP:More information form
To
Name of the person you want the Approval Server to ask for more Information. Unlike some fields, this field can contain only one name. Name of the person who is asking for more information. This field is read-only once the record is saved. Question regarding the information you want. Read-only field for the More Information requester because it is reserved for the response.
AP:Administration
285
AP:Notification
Process administrators use this form to create and modify notifications sent by approval processes.
Basic tab
Figure C-15: Notification formBasic tab
Type a name for the notification. Type the name of the process. Use the menu list to make sure you select only a process that exists on this server. Use the menu list to select the status of the notification. Active Inactive
Notify on
Use the menu list to select an event in the approval process that triggers this notification.
Qualification
Type additional conditions to the event that triggers this notification. In addition, you can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:
Submitter = "John"
In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
AP:Administration
287
Details tab
Figure C-16: Notification formDetails tab
Method
Use the menu list to determine the manner of notification. None sends no notification message. Alert notifies this person with AR System Alert. Email notifies this person through electronic mail. If the Send To field on this persons Notification form does not exactly match the name of an existing user, the system interprets the field as a literal address and sends the notification to that address. User Default notifies this person using the default notification method defined in their User record. If the User record does not contain a default notification method, AR System Alert is used. If you select Email or User Default, the Email tab is activated (see Figure C-17 on page 290).
Send to
Click this option button to determine who receives this notification. Notify List means the Approval Server sends default notifications. Other means you type manual notification recipients in the field to the right. Use the menu list to select a field reference (for example, $<field_name>$ for notification recipients. This field becomes activated when you select Other as the Send To option.
Subject
Type a subject line for the notification message. Use the menu list to select AR System variables to add to the subject.
Additional fields Use the menu list to select AR System variables to add to the additional fields. Message Type additional information to be the main body of the notification. Use the menu list to select AR System variables to add to the message. Select a priority from 0 to 10 to allow users to sort their notifications by order of importance. Entries created with an earlier version of the Approval Server will default to a Priority of 1.
Priority
AP:Administration
289
Email tab
Figure C-17: Notification formEmail tab
Mailbox name
Type the name of the mailbox that you want to handle the notifications if you do not want to use the default mailbox. You can also use the Fields or Keywords menu list to substitute a mailbox name. Type the name to be displayed to indicate where the mail is from. You can also use the Fields or Keywords menu lists to substitute a name. Type the name of people you want to receive email replies. if you enter a group name, a reply will be sent to all the names in the group. You can also use the Fields or Keywords menu lists to substitute a name. Type names of people you want to receive copies of this notification. You can also use the Fields or Keywords menu lists to substitute a name. Type names of people you want to receive copies of this notification but whose names you want hidden from the other recipients. You can also use the Fields or Keywords menu lists to substitute a name.
From
Reply to
CC
BCC
Organization Type a company name, an organization, a keyword, or a field reference to a name that you would like to appear on the email. Header Type the names of the templates to use for a header of the email notification. You can enter the name of the template directly, or enter a field reference or keyword that leads indirectly to a template name. Type the names of the templates to use for the content of the email notification. You can enter the name of the template directly, or enter a field reference or keyword that leads indirectly to a template name. Type the names of the templates to use for a footer of the email notification. You can enter the name of the template directly, or enter a field reference or keyword that leads indirectly to a template name.
Content
Footer
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Administration
291
AP:PreviewInfo
Process administrators use this form to preview all the approvers assigned to work on an approval request. You must enter data into all these fields to use the AP:PreviewInfo form. See Previewing approvers on page 218 for a discussion of this form.
Figure C-18: AP:PreviewInfo form
Selects which process the request belongs to. Entry number that you want previewed.
Users have an option of specifying a value as a qualification for the query being made. FullReturns list of all completed signatures (from the AP:Signature form), and all previews from the preview form. RemainingReturns list of only the preview signatures (those that are not yet opened and entered in the AP:Signature form). CompleteReturns list of only the signatures that have already been completed, that is, those that already exist on the AP:Signatures form, and are still open (Pending/More Info). You can query the AP:Signature form for this information as well, but users will view formatted data with this form.
AP:Process administrator
Process administrators use this form to create, delete, and modify the abilities of other process administrators. The AR System administrator uses this form to create the first process administrator after installation. See Setting up administrator capabilities on page 125 for a discussion of this form.
Note: The first process administrator must be created by your AR System Administrator.
Figure C-19: Process Administrator Privileges formProcess Administrator tab
Individual Authority
This field contains the user name of the individual who is to be a process administrator. Use the menu list to select the privileges allocated to the individual in the field preceding. Full Admin grants this person full authority as a process administrator. Override Only Admin grants this person only the authority to override a process.
AP:Administration
293
Notify method
Use the menu list to determine the manner of notification. None sends no notification message. Alert notifies this person with AR System Alert. Email notifies this person through electronic mail. If the Send To field on this persons Notification form does not exactly match the name of an existing user, the system interprets the field as a literal address and sends the notification to that address. User Default notifies this person using the default notification method defined in their User record. If the User record does not contain a default notification method, AR System Alert is used.
Covering
Click this option button to determine the processes for which this person receives process administrator privileges. All Specific Process
Use the menu list to select a process name if you selected Specific Process in the Covering field preceding. Use the menu list to determine the status of this persons process administration privileges. Active Inactive
Search Close
Click this button to perform your search. Click this button to close the window.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Process definition
Process administrators use this form to create and modify approval processes. See Using the Process Definition form on page 140 for a discussion about using this form.
Basic tab
Figure C-20: Process Definition formProcess Definition tab
Process Form
Type the name of this process. Type the name of the AR System form with workflow to be approved by this process, or select a form from the drop-down menu list. Use the menu list to select the process type for this process. See Approval process types on page 107 for a description of approval process types.
Type
AP:Administration
295
Status
Use the menu list to select the status of this process Active means this process currently generates approvals for the application determined in the application field preceding. Inactive means this process is disabled and generates no approvals for any application.
Type a valid user name or use the menu list to select the owner of a request in this approval process. Type in the name or use the menu list to select the approver to first see a request in this process. This field is required for Ad Hoc process type, optional if you allow Ad Hoc overrides, and otherwise unused.
Approval success Use the menu list to select the manner with which the Approval Server determines a request is complete. No More Approvers means a request is complete when all approvers have approved the request. Completion Rule means the request is complete when defined conditions have occurred. If multiple approvers Use the menu list to select the number of signatures required when multiple approvers appear on a signature line. One Must Sign means there is one signature line and the first approver to approve/reject a request determines the response. The request is withdrawn from the other approvers. All Must Sign means every approver on the signature line must approve the request. Allow Only One Approver means a response from more than one approver generates an error, and stops the approval process. Allow Ad Hoc next approver? Use the menu list to determine who can select an Ad Hoc next approver. Anyone means the requester and any approver can select an Ad Hoc next approver. Approver means any approver can select an Ad Hoc next approver. No one means this process never allows an Ad Hoc next approver.
Use the menu list to select what happens when the person who initiated the approval is not the owner of the request. Use Get Next Approver Rules uses the standard rules of the process. Assign to Owner if Approver assigns the entry to the owner of the request if that person is an approver. The Approval Server checks the Validate User rules to determine if the person is an approver. Always Assign to Owner assigns the entry to the owner for approval if this person did not request this approval.
Use the menu list to select Yes or No, whether Ad Hoc next approvers are validated before they can respond to a request. Use the menu list to select Yes or No, whether the approver must enter a password to save changes to an approval request. In Submit mode, click this button to perform your search. In Search mode, click this button to save your changes. Click this button to close the window.
AP:Administration
297
The three tabs (Normal, Urgent, and Low) on the Signature Escalation tab contain identical fields.
Use schedules Business calendar Use the menu list to select a workday schedule created on the form Business time workdays on page 315.
Holiday calendar Use the menu list to select a holiday schedule created on the form Business time holidays on page 315. Automatic action After interval Type a numeric value for the amount of time to pass before this notification occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days as the unit for the interval in the previous field.
Unit
Change state
Use the menu list to select the status you want to force on this request if there is no activity in the interval defined in the two preceding fields. Leave this field and the preceding two empty if you do not want the status of a request changed automatically.
Notification: still outstanding First interval Unit Repeat interval Type a numeric value for the amount of time to pass before this notification first occurs Select the unit of Hours or Days for the interval in the previous field. Type a numeric value for the amount of time to pass before this notification recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days for the interval in the previous field.
Unit
Notification: still in state On state Set the separate escalation and repeat intervals to occur when a form is saved with the status of Pending, Error, Hold, or More Information. Type a numeric value for the amount of time to pass before this notification first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days for the interval in the previous field. Type a numeric value for the amount of time to pass before this notification recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days for the interval in the previous field.
First interval
Unit
AP:Administration
299
Use schedules Business calendar Use the menu list to select a schedule created on the form Business time workdays on page 315.
Holiday calendar Use the menu list to select a schedule created on the form Business time holidays on page 315. Notification: still outstanding First interval Type a numeric value for the amount of time to pass before this action first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days for the interval in the previous field.
Unit
Repeat interval
Type a numeric value for the amount of time to pass before this action recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days for the interval in the previous field.
Unit
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Reserved word
Process Administrators use this form to create keywords and functions for approval processes.
Figure C-23: AP:Reserved word form
Type the name of the word you want to reserve. Click the option button to select whether the word is a keyword or function. Select name of special control group that you want to have access for row-level permissions.
AP:Role
Process administrators use this form to create role definitions within approval processes. See Defining roles on page 208 for a discussion about using this form.
AP:Administration
301
BMC Remedy Approval Server Figure C-24: AP:Role form, Role Information tab
Type the name for this role. Use the menu list to select how the approval process operates when many approvers appear in the Member List field. One must sign determines that only one signature is required from everyone indicated in the Member List field. All must sign determines that everyone indicated in the Member List field must approve the request. This field is valid only if there is more than one entry in the Member List field.
Status
Use the menu list to select the status of this role. Active means this role currently can be used by any approval process. Inactive means this role is disabled for all approval processes.
Type the user name for each person to participate as a member of this role. Use ; as a separator. In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Rule Definition
Process administrators use this form to create and modify rules for approval processes. See Using the Rule Definition form on page 154 for a discussion about using this form. You can dynamically define the search criteria by using the EXTERNAL keyword.
Basic tab
Figure C-25: Rule Definition formBasic tab
Definition Rule name Type a name for this rule. The name of a rule can be as long as 80 bytes. This equates to 80 characters in English and most European languages, but only 40 characters in double-byte languages. For process Rule type Use the menu list to select a process for this rule. Use the menu list to select the rule type. See Chapter 10, Defining approval rules, for a discussion of rule types.
AP:Administration
303
Status Order
Use the menu list to select the status of this rule. Type a number to determine execution order for this rule. Larger numbers execute after smaller numbers. Rules with the same number in this field execute in an unpredictable order.
If multiple results Use the menu list to select the behavior when there are multiple results. Value from first uses the value from the first record retrieved. Value from all uses all of the values retrieved. Return Error produces an error message if more than one record is retrieved. If multiple approvers Use the menu list to select the behavior when there are multiple approvers. One Must Sign means the Approval Server requires only one signature when there are multiple signature lines. All Must Sign means the Approval Server requires a signature for every signature line when there are multiple signature lines. Next approver rule is Use the menu list to select the behavior when there are multiple Get Next Approver rules. Additive means this rule appends approvers to the existing approver list, and further rules are processed. Ending means this rule appends additional approvers to the existing approver list, but no further rules are processed. Exclusive means this rule assigns the approver list, and no further rules are processed. If a previous rule created an approver list, the process ignores it. This field is generally used for a rule-based process that has a set of Get Next Approver rules for building an approver list.
Qualification Run if This field label appears by default but also if you select following from Rule Type menu list: Get Next Approver Validate Approver Get Authority Get Authority Regular Get Authority Self Prep Get Next Approver Enter the qualification in the Run If field. Use the buttons and menu list to help. See Using the Rule Definition form on page 154 for a discussion of creating rules. In addition, you can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:
Submitter = "John"
Rule
This field label appears if you select following from Rule Type menu list: Auto Approval Self Approval Completion Rule Enter the qualification in the Rule field. Use the buttons and menu list to help. See Using the Rule Definition form on page 154 for a discussion of creating rules. In addition, you can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:
Submitter = "John"
AP:Administration
305
Audit text
Type any text you want to appear in the permanent record for the request whenever this rule executes. Use the menu list to select keywords to include in your audit trail message.
Rule state Approved, rejected, cancelled, error This field label appears if you select Approval Process Done from Rule Type menu list. Select one or more rule conditions from among the radio buttons. The rule executes when the approval detail record is put in the selected state. Search Save Close In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
Use the menu list to select how the rule will populate this field type. Type the name of the form that contains the field you want to populate. Leave this field blank to use this rule on more than one form. This field is disabled with some options available in the Set Field Type field. Use the menu list to select the server that contains the form. Current means the form resides on the server with the Approval Server. Alternate means the form resides on another server indicated in the Server field. This field is disabled with some options available in the Set Field Type field.
On Server
Server
Type the name of the server that holds the form. This field is available only when the On Server field contains the value Alternate.
AP:Administration
307
Separator string
Type the letters, numbers, or symbols to use when separating multiple entries set in the same field. This field is disabled with some options available in the Set Field Type field. Type a qualification or use the menu list to select AR System functions or keywords. Based on the Set Fields Type you choose, the Qualification field enables different query options. For example, choosing SQL causes SELECT, FROM, and WHERE buttons to appear so that you can more easily construct SQL statements. In addition, you can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:
Submitter = "John"
Qualification
the value from the current transaction will be returned, "John " = "John". Fields data Field name Type a field name or use the menu list to select a field name. The Field Name field is disabled with some options available in the Set Field Type field. One rule can populate more than one field by using separate lines for Field Name and Value. Value Type the value to use for populating the field. The Value field is disabled with some options available in the Set Field Type field. One rule can populate more than one field by using separate lines for Field Name and Value.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Signature
Administrators can use this underlying helper form to review the responses to a request. However, you should modify this information only through the Approval Central application.
Figure C-27: AP:Signature form
Approval ID The AR System populates this field with the AR System ID for this request. Approvers The AR System populates this field with the names of persons who have approved this request.
More The AR System populates this field with the questions and answers information to More Information Requests. Approval status Next approver If multiple approvers The AR System populates this field with the status of the request. The AR System populates this field in an Ad Hoc situation with the name of the next approver. This option button is valid only if there is more than one entry in the Next Approver field. One must sign determines that only one signature is required from everyone indicated in the Next Approver field. All must sign determines that everyone indicated in the Next Approver field must approve the request.
AP:Administration
309
The AR System populates this field with your name if you are acting as alternate for this approval. Type the name of a valid approver to respond to this request. The AR System populates this field with the method by which this request was approved. Alternate means an alternate signed this request instead of a normally scheduled approver. Regular means a normally scheduled approver signed this request. Override means someone with process administration authority signed this request instead of a normally scheduled approver.
APW:Access Privileges
Approvers use this view on the web to create, delete, and maintain alternate approvers, and to log in as someone elses alternate. This form should not be used in BMC Remedy User. See Chapter 5, Processing approval requests with Approval Central, for a discussion of how to use this form.
Guide for Users and Administrators Figure C-28: APW:Access Privileges form
Approver The name of the individual who is to receive the approval (column in table) privileges. Click it to modify the alternate approver record in a separate window. Process name The process for which the alternate has authority. Blank if the (column in table) alternate has authority for all processes. Start date The date on which the alternates authority begins. (column in table) End date The date on which the alternates authority ends. (column in table) Status This field contains the status of the alternate: (column in table) Future means this alternate is not yet active. Current means the alternate is presently active. Add new approver (button) Click to add a new alternate approver.
AP:Administration
311
I would like to From the menu, choose the following: approve request: For Myself to log in as yourself and see your own approvals. For Someone Else and enter a name to log in as that persons alternate and see their approvals. As Override to see a list of the persons pending process records that you can approve or reject as the override approver. As Global Override to see a list of all pending process records that you can approve or reject as the global override approver. Change approver Click to make the new login effective. (button)
APW:Approval Central
Approvers use this view on the web as a launch pad to review their approval requests, access privileges, and More Information Requests. The fields in APW:Approval Central are not listed here because you customize this form as desired to fit your applications. See Chapter 5, Processing approval requests with Approval Central, for a discussion of how to use this form.
Guide for Users and Administrators Figure C-29: APW:Approval Central form
AP:Administration
313
BMC Remedy Approval Server Figure C-30: APW:More info Requests form
More info ID The request ID of this More Information request. Click it to (column in table) view or respond to the request in a separate window. To The name of the person from whom more information is (column in table) being requested. From The name of the person who is asking for more information. (column in table) More info status The status of the More Information request. (column in table)
Type a unique name for this holiday period. Type the dates included in this holiday period in the normal AR System format.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Administration
315
BMC Remedy Approval Server Figure C-32: Business Time Workdays formWorkdays Definition tab
Type a unique name for this workday period. In the Time Schedules tab, type a numeric time to indicate the hour and minute your company opens for business for each day of the week. If you are not open on a day, for example weekends, leave the Open Time fields for those days blank.
Close time
In the Time Schedules tab, type a numeric time to indicate the hour and minute your company closes for business for each day of the week. If you are not open on a day, for example weekends, leave the Close Time fields for those days blank.
Offset hours Enter amount of time to offset the start time by. If not specified, defaults to 1. This field allows you to calculate business hours into the single 0-24 hour range required by the AR System server. Scheduling diary Type text to document how the offset adjustment was performed.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:Administration
317
Appendix
Troubleshooting
This appendix contains troubleshooting information for the AR System Approval Server. The following topics are provided: Installation concerns (page 320) Approval Web concerns (page 322) Sample application concerns (page 322) Miscellaneous runtime concerns (page 323) Error messages (page 324)
Troubleshooting
319
Installation concerns
This section discusses known concerns regarding Approval Server installation.
Remedy Purchasing@Work 2.x, or earlier Remedy SetUp@Work 1.0, or earlier Remedy Change Management 3.x, or earlier
4 Verify that the Change option is set for the Group Type field. If this option is
Installation concerns
321
or
http://acme.remedy.com/arsys/apps/apex/ApprovalCentral/
or:
Approval-RPC-Socket: <number>
If both are specified, the Approval Server will use Approval-RPC-Socket: setting.
323
Error messages
These error messages are specific to the Approval Server.
4500 AR System Application server terminated when a signal/exception was received by the server. The approval engine was terminated by a signal. The process was terminated either accidentally or intentionally by a user in your environment. The number following this error is the signal that was received. If the signal is 15, you should be able to restart the server and continue to work. 4501 AR System Application server terminated -- fatal error encountered. A fatal error occurred within the approval engine. The details about that error are in an associated message. This message indicates that the error was fatal, and the approval engine is shutting down. 4502 Operation cancelled due to error. The command could not be performed due to an unspecified error. The command that failed is included in this message. 4503 4510 AR System Approval Server restarting. Two or more roles have the same name. The system encountered two or more entries in the Approval Role form for the name specified. The system does not allow this to exist. One name must be deleted or changed. The name is included in this message. 4511 No Approval Administration form was found. The system was unable to locate the Approval Administration form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted. 4512 No Approval Notification form was found. The system was unable to locate the Approval Notification form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted. 4513 No Approval Form form was found. The system was unable to locate the Approval Form form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4549
Confirming password is not valid for the current user. The approval process is configured to require the user to enter their password to approve or reject a request. The password either was not supplied, or the supplied password was not valid for the user performing the operation.
4550
Problem encountered during creation of one of the application forms. During the creation of the Application Pending form, an error occurred. There is an associated error message with the details of the problem. Correct the reason for the failure, and restart the arserverd process (or sent a SIGHUP signal) to recreate the form.
4551
Must be Application Server user to perform this operation. You must be the user (process) AR System Application Service to run the specified delete operation and mapping forms. The forms should be considered part of the system structure and should not be deleted or modified. To delete one or both of these forms, use AR System Administrator to select the forms for deletion, and ignore the system warning related to the forms.
4552
Two forms containing all the reserved application pending fields encountered -- delete one to continue. The System encountered two forms that have all the reserved application pending fields. The system cannot work correctly if there are two forms containing pending information. Delete one of the forms, or change it so that it is not considered an Application Pending form by removing fields in the 250 to 260 range. The two forms are identified in an associated message.
4553
No Application Pending form could be found on the server. An Application Pending form is required for the System to support application operations. No form containing all the special reserved application pending fields could be found. Load the Application Pending form.
4554
Failure during an attempt to perform an application command. The System received a request to record a command or encountered a situation in which it attempted to automatically record one, and a failure was encountered during recording. Thus, the command was not performed. The command that was attempted is displayed with this message, and an associated message contains more information about the failure.
4555
Command requires a form name be specified. The parsing or formatting command requires a form name. None was specified. Check the syntax of the command and enter a form name as required.
4556
Form name specified on command is not valid. The form name specified is not a valid form on the system. The form name specified must be the name of an existing form.
Error messages
325
4557
Parse set fields command requires two forms be specified. The parse set fields command requires that two forms be specified. Either none, or only one, was specified.
4558
Qualification line error. An error was detected in the qualification line. There is additional information indicating the error and the position in the qualification where the error occurred.
4559
Assign line error. An error was detected in an assignment line. There is additional information indicating the error and the position in the assignment where the error occurred.
4560
No Approval Details form could be found on the server. A request was made for finding forms joined to the Approval Details form. However, there is no Approval Details form on the system. Generally, this means that the Approval subsystem is not installed. The command is not valid without the Approval subsystem.
4561
Command requires a field name be specified. The command requires that a field name be specified. Review the syntax and retry the command with the appropriate field name specified.
4562
Field name specified on command is not valid. The field name specified for the command is not a valid field name within the indicated form. The command requires that a valid field name be specified.
4563
Command requires a entry ID be specified. The command requires that a Request ID be specified. Review the syntax of the command, then retry the operation.
4564 4565
Entry ID specified on command is not valid. The Request ID specified for the command is not a valid Request ID. No Approval Signature form could be found on the server. A request was made that requires access to the Approval Signature form. However, there is no Approval Signature form on the system. Generally, this means that the Approval subsystem is not installed. The command is not valid without the Approval subsystem.
4566
No Approval Detail-Signature join form could be found on the server. A request was made that requires access to the Approval Detail-Signature form. However, there is no Approval Detail-Signature form on the system. Generally, this means that the Approval subsystem is not installed. The command is not valid without the Approval subsystem.
4577
No Approval Server licensecannot run the approval engine. The Approval Server checks licensing to determine if a server is licensed for approval functionality. For there to be an approval license, there must be a valid server license. This is because the server license is the base license of the product and the approval license is an option. Check to make sure that the server license is valid and implemented.
4578
There are two forms with the same license tag. Limited licensing for approvals and the system encountered two forms with the same license tag. Only the first form found with the given tag will be loaded.
4579
Limited licensing for Approvals and no form was found linked to any license. Limited licensing is in effect for approvals, and the system was unable to find any form with the tags in the limited license tag list. This is an error condition.
4580
Form is not licensed to work with the approval engine. Limited licensing for approvals and the system was unable to find a license in the limited license tag list for the form specified. The form name is identified in this message.
Malloc failed in Approval Server. Another copy of the Approval Server is already running or the Application Dispatcher is in use. Error while opening the Approval Server lock file. The system encountered an error while attempting to open the Approval Server lock file <arserver_install_dir>\arserver\db\ar.lck.390609.
4584
There are two forms identified as the Approval Detail form. The system encountered two forms designated as the Approval Detail form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4585
There are two forms identified as the Approval Signature Line form. The system encountered two forms designated as the Approval Signature Line form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4586
No Approval Signature Line form was found. The system was unable to locate the Approval Signature Line form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
Error messages
327
4587
There are two forms identified as the Approval Process Definition form. The system encountered two forms designated as the Approval Process Definition form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4588
No Approval Process Definition form was found. The system was unable to locate the Approval Process Definition form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4589
Command requires form and entry ID be specified. Parameters are missing from the command to the Approval Server. An associated message with the actual command has been sent to the Approval Process administrator.
4590
There are two forms identified as the Approval Rule Definition form. The system encountered two forms designated as the Approval Rule Definition form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4591
No Approval Rule Definition form was found. The system was unable to locate the Approval Rule Definition form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4592
There are two forms identified as the Approval Alternate form. The system encountered two forms designated as the Approval Alternate form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4593
No Approval Alternate form was found. The system was unable to locate the Approval Alternate form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4594
There are two forms identified as the Approval More Information form. The system encountered two forms designated as the Approval More Information form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4595
No Approval More Information form was found. The system was unable to locate the Approval More Information form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4596
There are two forms identified as the Approval Process Administrator form. The system encountered two forms designated as the Approval Process Administrator form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4597
No Approval Process Administrator form was found. The system was unable to locate the Approval Process Administrator form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4598
There are two forms identified as the Approval Role form. The system encountered two forms designated as the Approval Role form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4599
No Approval Role form was found. The system was unable to locate the Approval Role form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4600
Cannot create new approval detail as is already an active detail entry. An approval is already in progress for the indicated approval process and entry ID, so a new approval detail entry will not be created.
4601
Multiple rows matched next approver condition and configured to error. More than one Next Approver record was returned for the entry, and a Get Next Approver rule for the approval process is configured to return an error when multiple rows are returned. The operation has stopped. You must either change the rule to allow multiple next approvers, or specify only one next approver for this entry.
4602
AR System server does not support AR System Application Service user. This can occur when using AR System 5.1 with Approval Server 4.x. Either upgrade your Approval Server to 5.1 or remove your AR System Application Service password.
Error messages
329
4603
Field specified for first approver is not defined on the form. The field defined to specify the first approver for the process does not exist on the application form. The field ID is appended to this message. If the process is defined as Ad Hoc, the operation has stopped. If the process is defined so that Anyone can specify the next approver (see Creating a process on page 140), the operation continues after this warning.
4604
Sig-xxx command requires form to be the approval signature line form. The command issued (sig-approved, sig-rejected, sig-cancelled, sigreassign, sig-notify) must come from the AP:Signature form.
4605
Sig-xxx command requires process to match details if process is specified. The process specified in the command issued (sig-approved, sig-rejected, sigcancelled, sig-reassign, sig-notify) does not match the process specified in the details record of this pending approval request.
4606
No process specified but there are two or more for form so cannot continue. Your application has two or more approval processes configured for it, but the command issued (Add-sig or New-details) did not specify which one to use for the new approval.
4607
Process allows only one next approver but two or more were specified. The process was configured to allow only one approver, but more than one approver was entered in the Next Approvers or Reassign To field.
4608
MoreInfo-xxx command requires form to be the More Information form. The MoreInfo-Return command issued must come from the AP:More Information form.
4609
A process was specified but no process by that name exists. The process specified in the AP:Notification entry or in the command issued (Addsig, New-details, sig-approved, sig-rejected, sig-cancelled, sig-reassign, or sig-notify) does not exist.
4610
No active process is associated with this form. No process is associated with your approval application form, so the operation has stopped. You must configure a process for a form before using it for approvals.
4611
No join is defined between the form and the approval detail form. Before you use the Approval Server with your application you must join your application form to the AP:Detail form. Instructions for this are provided in Chapter 13, Adding approvals to your application.
4612
No join is defined between the approval detail and signature line forms. Before you use the Approval Server with your application you must join your application form to the AP:Detail-Signature form. Instructions for this are provided in Chapter 13, Adding approvals to your application.
4613
Update-Config command requires tag. The Update-config command issued did not have any tag for the config parameter. If you are making approval configuration changes in the Server Settings form, try again.
4614
Failure trying to map names to IDs in a string. The field names specified in the Send to Other, Subject and Message fields in the AP:Notification entry could not be converted to their field IDs. The actual error is appended to this message.
4615 4616
Failure trying to retrieve join of a form with Detail-Signature. See error number 4612 on page 331. There are two forms identified as the Approval Administration form. The system encountered two forms designated as the Approval Administration form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4617
There are two forms identified as the Approval Notification form. The system encountered two forms designated as the Approval Notification form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4618
There are two forms identified as the Approval Form form. The system encountered two forms designated as the Approval Form form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
The Completion field is required on Detail form but is not present. The field Completed?, ID 13004, is missing from the AP:Detail form. The Form field is required on Detail form but is not present. The field Application, ID 10050, is missing from the AP:Detail form. The Entry ID field is required on Detail form but is not present. The field Entry ID, ID 8, is missing from the AP:Detail form. The Next Approver field is required on Sig Line form but is not present. The field Next Approvers, ID 13205, is missing from the AP:Signature form. The Process field is required on Detail form but is not present. The field Process, ID 10000, is missing from the AP:Detail form.
Error messages
331
Appendix
This appendix contains the information about Approval Server installation directories. The following topics are provided: Default installation directories (page 334) Directory structure for Windows installations (page 334) Directory structure for UNIX installations (page 335)
333
335
Glossary
access control active link
A security feature in which AR System administrators limit the access users have to forms, to specific fields or records within a form, to workflow, and to specific functions within the system. See also group, permission, user.
action request
An ordered sequence of active links that together accomplish a specific operation. Active link s can help lead users through a task (like a wizard) or can be used as subroutines to accomplish common tasks. Compare with filter.
Ad Hoc
A collection of information that describes something, such as a problem or a service request. See also approval request.
Action Request System (AR System)
Adaptable client/server software that provides a foundation for creating applications that can automate, track, and manage a wide variety of business processes.
active link
An approval process type with no predictable routing, in which each approver selects the subsequent approver. See also Parent child, level, and rule-based process types.
administrator
A workflow component that causes a AR System client to perform specific operations in response to specific user actions. They are generally used to assist users with interactions with the system. Active links run on the client machine.
The value that AR System administrators assign to a field while designing a form. When users set defaults, this value is automatically entered in the field. Users can override the administrator default by assigning their own default or by entering a different value. See also user default.
Glossary
337
Administrator group
application
One of several special access control groups that the AR System provides. Members of this group have full and unlimited access to the AR System including unlimited ability to create definitions and access and modify data. See also Subadministrator group.
advanced search bar
The row of buttons, the Search Criteria field, and the Fields menu list that appear at the bottom of the BMC Remedy User Detail pane when you click the Advanced button in BMC Remedy User. You can use this bar to specify complex search criteria.
alert
A group of forms and the associated workflow collected by an administrator that are related to a business function; for example, Employee Care or Help Desk. An application is also a server object in BMC Remedy Administrator. An application can include one or more AR System forms that contains entries that need to be approved.
application program interface (API)
A notification from an AR System server or other program to the user that certain conditions have occurred, such as a request has been submitted or progress has been made in resolving a request.
alert list
A set of functions that provides application programmers with access to the full functionality of a product. The AR System API is documented in the C API Reference guide.
approval process
A procedure that generates all necessary signatures for authorizing a particular AR System application form.
approval process done
The list of alerts belonging to a user that can be displayed in BMC Remedy User or on a web client.
alternate
A rule type used to update the request when the approval process is done. These rules are used to indicate the result of the approval process to the original request.
approval request
An AR System user with the authority to substitute for an approver within an approval process.
alternate approve
A specific instance of an approval process for authorizing a particular AR System application form.
Approval Server
A module within the AR System which routes forms to generate appropriate signoff signatures. The Approval Server also creates an audit trail for authorizing AR System application forms.
approved
The status of a completed approval request when all approvers have responded with agreement.
338 Glossary
approver
Assignee group
The list of approvers eligible to respond on signature lines for an approval process.
ARDBC
One of several special access control groups that the AR System provides. Users automatically belong to this implicit group for requests for which they have been assigned responsibility (that is, their name is in the Assigned To field). See also Assignee Group group, Submitter group.
Assignee Group group
An individual responsible for the management of the AR System, including setting up forms, setting access rights for users, and designing the workflow process. See also process administrator.
AR System client
One of several special access control groups that the AR System provides. Users automatically belong to this implicit group for requests for which they are a member of a group assigned responsibility (that is, they are a member of a group whose name is in the Assignee Group field). See also Assignee group, Submitter group.
attachment data type
The subset of AR System software that enables users to access an AR System server.
AR System database connectivity (ARDBC)
The data type used for fields that need to hold files. This type enables you to store text, graphics, audio, or video attachments in the database.
attachment pool field
A mechanism by which the AR System server uses a plug-in to access data stored externally to the AR System database as if it were within the AR System.
AR System external authentication (AREA)
A field that contains a set of one or more related attachment fields to organize attachments associated with an action request.
auto approval
A mechanism by which the AR System server can access and use authentication services from outside the AR System environment. A plug-in is developed to allow access to the external subsystem.
AR System server
A rule type that allows for automatic approval of a request for any submission that meets specified criteria.
The subset of AR System software that provides the data storage and main processing environment for the AR System.
Glossary
339
The AR System client tool used by AR System administrators and subadministrators to set up the system for users. Use AR System Administrator to create and change structure definitions. AR System Administrator is also used to set access permissions that determine which users and groups can view or modify each form or specific parts of a form.
BMC Remedy Alert
The AR System client tool in which users enter and track requests through the resolution process. Users can also search the database, generate reports, and modify existing requests.
button field
A field on a form that a user can click to execute an active link. A button, image, or hyperlink can represent a button field. See also menu item, toolbar button.
cancel at later level
The AR System client tool through which an alert can be sent to a user. See also notification.
BMC Remedy Configuration Tool
An indication for notifications when an approval process is cancelled after it has been approved by a previous approver.
cancelled
The tool used to configure and manage the mid tier portion of the AR System.
BMC Remedy Email Engine
The status of a completed approval request which was withdrawn by the requester.
chained approval process
A server-based application that communicates with both the AR System server and an email server. The BMC Remedy Email Engine receives emails, and can parse and interpret these messages to execute specific instructions on an AR System form. It also sends emails the AR System and directs notifications as a result of filters and escalations.
BMC Remedy Import
A sequence of approval processes which appear to the user as one approval, but in fact are made up of many separate approval processes.
change flag
A status flag set when the contents of a field or form have been altered. A change flag can be polled or disabled by workflow.
character data type
The AR System client tool that enables AR System administrators to transfer data records from an archive file into a form.
BMC Remedy License
The data type used for fields that contain alphanumeric text.
character menu
The AR System client tool used to apply and review software licenses that activate features of the AR System software.
A menu that the AR System administrator can create to provide assistance with filling in values for a field. You can attach a menu to any character field. See also dynamic menu.
client
340 Glossary
client tier
control panel
The architecture level where AR System clients operate within the multitier system.
close approve
A form used as a centralized entry point from which users choose the business tasks they want to accomplish.
core field
An indication for notification when a request has multiple possible approvers and another of the approvers approves the request.
closed
One of a set of basic fields common to all AR System regular forms. AR System administrators cannot remove these fields from a regular form.
Customize group
The status of an approval request that has been resolved and is no longer waiting for an approver or more information response.
close reject
An indication for notification when a request has multiple possible approvers and another of the approvers rejects the request.
command-line option
One of several special access control groups that the AR System provides. This group grants users the right to customize their form layout in BMC Remedy User.
data field
A parameter used to specify an operation or option to AR System tools when they are run.
completion rule
A field that stores data in the database. Data fields include character, date/time, diary, integer, real, decimal, selection, and attachment.
data tier
A rule type that checks whether conditions exist to stop routing a request. If a completion check is successful, then no new approvers will see the request. The request might not be done, but the request has been routed to everyone who must respond.
container
The architecture level that contains data and communicates with the AR System server. The data can be stored in a text file, spreadsheet, or database internal or external to the AR System.
data type
The underlying data structure for s and applications. A component of the AR System used to store collections of objects. Used as the basic storage structure for applications, active link s, filter s, and packing lists.
control data type
The property of a field that determines the characteristics of the field and what type of information (if any) the field contains.
date/time data type
The data type used for fields containing date/time timestamp values.
decimal data type
The data type for fields that execute active links. These fields do not contain data.
A field that accepts and contains fixed-point numbers. This type of field enables you to store quantitative information in a request.
default
Glossary
341
Details pane
The part of the main window in BMC Remedy User that displays fields for entering or viewing data.
dialog box
An interapplication communication feature used in Windows applications. For more information, see your Windows documentation.
dynamic menu
A message displayed to users that must be responded to before users can continue filling out a form. The administrator creates a dialog box by using an active link action.
diary data type
The data type used for fields that enables you to capture a history of the actions taken for a request. The field stores character data. It is an append-only field, and each addition is stamped with the time, date, and name of the user who entered the item.
display-only field
A menu that causes a search to be performed when a user selects the menu button. The results of the search are used to build the list of items from which the user can choose. See also character menu.
entry
A temporary field for which no space is allocated in the database. See also global field.
display-only form
The status of an incomplete approval request in which routing problems have occurred.
escalation
A type of form containing display-only fields. Display-only forms are used to create control panels and dialog boxes.
distributed server
An AR System server that exists within a multiserver, distributed environment. See also Distributed Server Option.
Distributed Server Option (DSO)
A workflow component that searches at specified times or at regular intervals for requests matching a specified condition and performs specified operations on all matching requests. They are generally used to find records that have exceeded desired business rules or processes and take appropriate action. Escalations run on the AR System server.
event
An AR System server option to send and receive data from both similar and dissimilar forms on physically separate servers. DSO requires a separate usage license. See also distributed server.
done
An occurrence in the AR System that can serve as a trigger for other events or workflow. Examples include user interactions with an AR System form (such as opening windows, tabbing from field to field, switching row focus, and so on), state transitions of requests, or any condition that arises while manipulating a request.
342 Glossary
export
filter API
1. The AR System Administrator command that transfers definitions in a file; for example, forms, filters, active links, and mail templates. 2. The ability to transfer one or more data entries to a file for archive or transfer by using the reporting feature in BMC Remedy User. See also import.
field
An AR System plug-in API that allows inline access during filter and escalation processing to extended servers.
filter
An ordered sequence of filters that together accomplish a specific operation. Filter s can be used as a subroutine to accomplish common tasks. Compare with active link.
fixed license
In the AR System, the main entity of a form. All of the following are AR System fields: data, table, page, active link control (buttons, menu items, and toolbar buttons), and trim.
field ID
A license permanently assigned to a user, enabling access to the licensed features of the AR System at any time. See also floating license, write license.
floating license
A unique numeric identifier that is assigned to each field. Once assigned, it cannot be changed.
field label
A name supplied by the administrator that describes the fields purpose. Intended for display to the user.
field name
A license that is temporarily allocated to a user who requests a license and who is defined as using a floating license. If no floating license is available at the time of the user request, the user must wait until a license becomes available. See also fixed license, write license.
form
A unique character identifier that is assigned to each field. The name can be changed at any time as long as the new name is unique.
file menu
A menu with items retrieved from a file that contains a formatted character menu.
filter
A collection of fields that represents a record of information in the AR System. AR System administrators can define and change the fields and workflow associated with a form. An AR System application can include many forms.
form action field
A workflow component that tests every server transaction for certain conditions and responds to the conditions by taking specific actions. They are generally used to check and enforce business rules and processes. Filters run on the AR System server.
One of a set of special fields that provide the standard functions of the web client interface. Some of these include submit, query, modify, and the advanced search bar.
Glossary
343
form view
global field
The screen layout for a form, which appears in the Details pane of BMC Remedy User. AR System administrators can create and name multiple form views, which can be further modified by users with Customize permission. Administrators can include different fields and can hide fields in various form views.
function
A display-only field used in multiple forms. The value contained in the global field is duplicated across all forms that contain the field.
group
A named procedure that performs a distinct service in the AR System. The AR System API has a set of function calls used to accomplish AR System tasks. Additionally, there are table functions that you can use to perform mathematical operations on table data.
get authority
A category in the AR System used to define user access to form fields and functions. The AR System defines several special groups: Public, Administrator, Subadministrator, Customize, Submitter, Assignee, and Assignee Group. You can define additional groups through the Group form. See also access control, permission, user.
Group form
The form in which you add new groups, delete groups, and modify group permissions.
guest user
A rule type that gathers information about the current approver or environment that is used by subsequent self-approval or completion rule tests.
get authority regular
A rule type that gathers information about the current approver or environment that is used by subsequent completion rule tests. Note that these rules are not run before selfapproval tests.
get authority self
An unregistered user with a limited set of capabilities (submit requests and possibly review those requests). The administrator can specify whether unregistered users are allowed at your site.
See active link
And filter.
hidden field
A rule type that gathers information about the current approver or environment that is used by subsequent self-approval rule tests. Note that these rules are not run before completion tests.
get next approver
A field that exists but is not visible in a users view of the form.
hold
A rule type that finds the next approvers in the current process, including the first approver at the start of processing.
An indication for notifications when a request is changed to the Hold status. This is also a status where an approval request is assigned to an approver but no Approval Server activity occurs.
344 Glossary
import
level
1. The AR System Administrator command that transfers definitions from an export file to the current server. 2. The AR System import command that transfers one or more data entries from an archive file to a form. See also export.
integer data type
The data type used for fields that contain numeric values between 2147483647 and 2147483647. The range for a field can be limited by the AR System administrator.
join form
An approval process type with no fixed relationship between the approvers, but rather some relationship based on their membership in some group. Often used with approval processes requiring consensus from set of committees where the individuals are related only by their membership on the committees. See also Parent child, Ad Hoc, and rulebased process types.
license
A type of form that contains information from two or more AR System forms. Although join forms function similarly to regular AR System forms in most respects, they do not store independent data. Join forms point to the data stored on the AR System forms that were used to create the join form.
keyword
A set of operations within BMC Remedy User recorded for later execution. Macros are useful for automating frequently used or complex operations.
macro bar
A variable whose value is defined by the AR System. For example, $USER$ represents the name of the user that is currently logged in. Keywords can be used in defining qualifications for searches, search menus, workflow, and macros; or for specifying a value in the Set Fields action for active links, filters, and escalations.
The row of buttons below the menu bar in BMC Remedy User that enables easy access to commonly used macro commands. Macro commands are also available from the Tools menu.
mail template
A template that enables you to submit a request by using electronic mail. The AR System administrator generates templates from an existing form by using the export command.
main form
A form that users interact with directly. An application might use more than one main form. Main forms are sometimes called primary forms.
Glossary
345
main window
ODBC
The BMC Remedy User window that displays a form in the Details pane and, optionally, the results of a search in the Results pane and prompt text in the prompt bar. The main window includes a menu bar and optional status bar, toolbar, and macro bar.
menu item
Open Database Connectivity (an SQLbased communication standard developed by Microsoft)a connectivity solution that enables the AR System to communicate with ODBC clients.
override approve
An indication for notifications when a process administrator has approved a request in a manner that circumvents the normal process.
override reject
The architecture level consisting of add-in services that communicate between AR System servers and various clients. BMC Remedy User can communicate directly with AR System servers. However, browser clients must use the mid-tier addin services to communicate with AR System servers.
more information
An indication for notifications when a process administrator has rejected a request in a manner that circumvents the normal process.
packing list
A set of associated server objects that can be viewed as a work space in the server window or used in external utilities.
page field
An approvers query for additional data that becomes part of the audit trail of the approval request. The approver is not required to delay the approval request until someone responds.
more info return
A type of field that provides an area to group related fields. See also page holder field.
page holder field
An indication for notifications when a more information request has been responded to.
new signature
A field that contains one or more page fields that allows display of one of the grouped field sets at a time in a given area of the screen.
parameterized get next approver
An indication for notifications that a new signature record has been created with an individual as an approver.
notification
A message to a user from workflow. Notifications can be alerts, email messages, or other methods using integrations.
A rule type that finds the next approvers in the current process, including the first approver at the start of processing. This rule lets you add additional Ad Hoc approvers to any stage in an approval process.
346 Glossary
parent-child
process administrator
An approval process type with a fixed relationship between approvers, such as found in a management hierarchy. See also level, Ad Hoc, and rule-based process types.
pending
An AR System user who is a member of the Approval Admin group (402) and has authority to set up and maintain approval processes. See also AR System administrator.
prompt bar
The status of an incomplete approval request that is waiting for response from an approver or more information.
permission
The part of the main window in BMC Remedy User that displays instructions or useful information about the form it is attached to.
Public group
The property setting that enables AR System administrators to control who can view and change individual fields of a form. Administrators also set permissions for forms, active links, active link s, and applications. See also access control, group, user.
plug-in
One of several special access control groups that the AR System provides. Every user is automatically a member of this group.
qualification
An auxiliary program that works with the AR System server to enhance its capability. A plug-in is a dynamically linked library (DLL) on Microsoft platforms and a shared object on UNIX platforms. The plug-in service loads the plug-in at runtime.
plug-in service
A search criteria including field references, values, and arithmetical and relational operators used to find a set of data that matches the conditions specified.
query-by-example (QBE)
A server that loads plug-ins. The plug-in service is a companion server to the AR System server that loads the ARDBC, AREA, or Filter API plug-ins at runtime.
preference server
A method for describing a database search visually. An empty form is displayed and the search conditions are typed in or selected in their respective fields. The AR System turns the visual query into the proper command language, such as SQL, necessary to interrogate the database.
read license
An AR System server that stores user preferences centrally in one or more preference forms.
prep get next approver
A license that allows a user to search the AR System forms and to submit new requests but does not allow the user to modify existing requests. See also write license.
real data type
A rule type that gathers information to be used by the get next approver rules.
The data type used for fields that contain floating-point numbers. The range and precision can be set by the AR System administrator.
Glossary
347
reassign
reserved field
One of a set of fields with specific rules and interpretations that are defined by the AR System.
results list
A form used to manipulate and display data. These forms and their contents are stored in database tables created, owned, and managed by the AR System server.
reject by another approver
An indication for notifications when there are multiple required approvals outstanding and one of the other approvers rejects the request.
reject by later level
1. A list of requests that match a search. 2. An AR System server object for displaying search results that can be added to forms and views. Multiple rows (for example, requests) in the results list that meet specified criteria can be selected for further processing.
Results pane
An indication for notifications when an approval process is rejected by an approver after it has been approved by a previous approver.
rejected
The part of the form window in BMC Remedy User that displays the results of a search.
role
A named alias for one or more approvers. Allows the definition of a position regardless of the individual approvers who are currently fulfilling that position.
rule-based
The core field on a form that contains the unique numeric identifier for a request or entry in the AR System. In join form entries, the Request ID field contains the Request ID field contents for each of the underlying forms, separated by a vertical bar. Previously called an entry ID.
requester
A custom approval process type set up by the process administrator. There are no assumptions about relationships between approvers. Everything is built into the rules. See also Parent child, level, and Ad Hoc process types.
search
The process in which users display a subset of requests according to search criteria that they define.
search menu
A user who submits a form that requires authorization, triggering the Approval Server.
A menu whose items are based on data retrieved from a search of an AR System form.
348 Glossary
statistical override
The data type used for fields with a set of mutually exclusive choices. The selections are displayed as option buttons or as a list of items.
selection list
A rule type that is used to preempt the default behavior of the approval process and follow an approve or reject path before all pending signatures have been completed.
status bar
A list that appears when an active link performs a search that returns more than one request.
self-approval
The part of a main window in an AR System client that displays instructions or useful information to the user.
Status field
A rule type that allows for automatic approval of a request if the submitter of the request has sufficient authority for the request to be approved.
server
The core field in which the AR System tracks the various stages of the resolution process for a request.
status history
The architecture level consisting of the AR System server that controls access to the data and any supporting services called by or used by the AR System server.
signature accumulator
Information that shows what progress has been made on a request. Users can view status history from any display showing the contents of an entry.
subadministrator
A rule type that is used to collect statistical information about the signature records associated with an approval process.
signature record
A database record for the signature of an approver. If an approval request requires more than one signature, then multiple signature records are generated for that single approval request.
source control
One of several special access control groups that the AR System provides. Members of this group have limited administrative access to the AR System as defined by an administrator. See also Administrator group.
Submitter group
One of several special access control groups that the AR System provides. Users automatically belong to this implicit group for requests they have submitted (that is, their name is in the Submitter field). See also Assignee group, Assignee Group group.
supporting form
A menu whose items are based on data retrieved from a direct SQL command to the AR System database.
Glossary
349
table field
validate approver
A field that displays data from other requests within the context of the current request. The data appears in a spreadsheetstyle format.
task
A rule type that is used to verify that a name specified as the next approver is a valid user. Only used to verify a user specified in an Ad Hoc process or an Ad Hoc override of another process type.
variable
A shortcut or link created in BMC Remedy User that enables users to quickly open a specific form, search, application, or active link.
toolbar
The row of buttons below the menu bar in BMC Remedy User that enables easy access to commonly used menu commands.
toolbar button
Forms that allow users to connect to external data sources, such as text or spreadsheet data, that reside on local or remote servers.
view
In BMC Remedy User, an icon for a menu item that triggers an active link. See also button, menu item.
trim data type
The data type of fields that enhance a forms usability and appearance. Trim includes lines, boxes, text, and URL links. These fields do not contain data.
user
Field that provides a browser window within a form. Can be used to display a URL, the contents of an attachment, or direct HTML text.
view form
Any person with permission to access the AR System. See also access control, group, permission.
user default
Forms that allow users to connect to external database tables accessible by the AR System database user.
view user interface (VUI)
A value or set of values that a user can predefine. A user default overrides an AR System administrator default. See also administrator default.
User form
An AR System client that runs in a browser to provide a user interface to AR System applications.
wildcard
The form in which administrators add users to the AR System and specify each users type of access and login information.
A character that users can enter to represent other characters in a search. For example, in search statements in character and diary fields, users can specify wildcards to match single characters, strings, or characters within a range or set.
350 Glossary
workflow
1. A set of business processes used to run a company. 2. The automation of business processes through actions performed by active links, filters, and escalations.
work space
A subset of all objects on the server displayed in AR System Administrator. This subset of server objects is defined in a packing list.
write license
A license that allows a user to modify and save data in existing requests as field and form permission settings allow. See also fixed license, floating license, read license.
Glossary
351
352 Glossary
Index
A
access privileges 66 accessing approval module forms 118 Approval Server with web clients 119 active links for Lunch Scheduler 224 active signature record 99 ad hoc approvers 94 defined 337 defining processes 142 process type versus ad hoc override 94, 112 sample application 74 ad hoc process described 112 Get Next Approver rules 169 Parameterized Get Next Approver rule 113 adding alternate approvers 70 Add-PGNA-Values command 259 Add-Sig command 258 multitenancy 258 administration 119 Approval Server 117 URL 119 administrators defined 339 setting capabilities 125 administrators, process assigning capabilities 125 authority of 84 defined 84 delegating authority 85 Override Only 85 responsibilities of 84 Specific Process 85 All must sign field 171, 175, 209 alternate approvers access privileges 66 adding 70 assigning 49, 66 creating for others 70, 209 defined 42 modifying information 69 serving as 50, 68 alternate reject 338 answering approval requests 56 More Information requests 63 AP:Admin-DeleteVerify dialog 270 AP:Administration form 118, 234, 269 AP:Admin-Rename dialog 121, 271 AP:Admin-ServerSettings dialog 127, 272 AP:Alternate form 276 AP:Detail form 85, 279 AP:Detail-Signature form 232, 280 AP:Dtl-Sig-MoreInfoDialog dialog 283 AP:Form form 284 AP:More Information form 86, 242, 285
Index
353
AP:Notification form 243, 286 AP:PreviewInfo form 292 AP:Process Administrator form 125, 211, 292, 293 AP:Process Definition form 140, 242, 295 AP:Reserved Word form 301 AP:Role form 208, 301 AP:Rule Definition form entering rule information 156 field descriptions 303 opening the form 154 setting field values on forms 157 tabbed views 154 AP:Signature form 86, 309 Application Pending form 20, 256, 321 Application-Command process 256 applications connecting to Approval Server 230 Get Agreement 73 licensing forms 20 Lunch Scheduler 213 troubleshooting sample 322 Approval Central form 268 hidden characteristic 231 logging in with User tool clients 56 logging in with web clients 54 URL 54, 322 approval errors 49 approval module, accessing forms 118 approval notifications 116 Approval Process ad hoc 112 creating 84, 140 defined 34 deleting 150 diagram of 88, 106 done versus complete 89 error handling 49 licensing forms 20 modifying 149 reassigning requests 48, 61 requesting more information 47 restarting 222 specifying next approver 48, 60 viewing approval request records 46
Approval Process Done rules creating 201 described 201 example of 202 worksheet 253 Approval Process, types of ad hoc 169 level 110, 169 parent-child 108, 168 rule-based 114, 170 summary table 114 approval processes for Lunch Scheduler 216 approval requests audit trails 85 defined 338 diagram of 88 login list 55, 57 processing 46, 54, 119 reassigning 48, 61 responding to 56, 96 sample application 73 specifying next approver 48 status of 47 viewing 46, 58 approval routing, setting up 84 approval rules defined 87 deleting 206 modifying 205 approval rules, types of Approval Process Done 201 Auto-Approval 159 Completion 187 Get Authority 91, 181 Get Authority Regular 183 Get Authority Self 91, 185 Get Next Approver 94, 168, 174 Prep Next Approver 165 Self-Approval 92 Signature Accumulator 189, 190 Statistical Override 193 Validate Approver 94, 179
354 Index
Approval Server accessing components 120 accessing with web clients 119 administration 117 ARDBC plug-in, using 27 configuring 122 connecting applications to 230 deadlocked ARDBC plug-in 323 debugging 122 defined 338 incompatibility with bundled version 320 installing on Windows 21 licensing before installation 321 licensing forms 20 manually starting and stopping 27 performance 67 previous installation 320 purchasable license not required 20 URL 54, 322 Approval Server commands Add-PGNA-Values 259 Add-Sig 258 Det-Approved 259 Det-Cancelled 259 Det-Error 260 Det-Rejected 260 MoreInfo-Return 261 New-Details 261 Rename-Form 262 Rename-Process 262 Sig-Approved 262 Sig-Cancelled 263 Sig-Notify 263 Sig-Notify-Change 264 Sig-Notify-State 264 Sig-Reassign 265 Sig-Rejected 265 Update-Config 265 Approval Server dialogs AP:Admin-DeleteVerify 270 AP:Admin-Rename 271 AP:Admin-ServerSettings 127, 272 AP:Dtl-Sig-MoreInfoDialog 283 Approval Server for the Web. See Approval Web
Approval Server forms AP:Administration 269 AP:Alternate 276 AP:Detail 279 AP:Detail-Signature 280 AP:Form 284 AP:More Information 285 AP:Notification 286 AP:Process Administrator 292, 293 AP:Process Definition 295 AP:Reserved Word 301 AP:Role 301 AP:Rule Definition 303 AP:Signature 309 Approval Central 268 APW:Access Privileges 310 APW:Approval Central 312 APW:More Info Requests 313 Business Time Holidays 315 Business Time Workdays 315 User 317 Approval Web configuring without portmapper 30 notes on installation 20 processing requests 54, 119 requesting more information about approvals 62 responding to More Information requests 63 reviewing requests 58 troubleshooting 322 URL 54, 322 viewing More Information requests 63 Approval Web, alternate approvers designating 66 modifying 69 reassigning approval requests 61 reviewing 68 serving as 68 Approval Workspace field 221 approval, defined 34
Index
355
approvers ad hoc 94 approving requests 89 assigning alternate 49, 66, 209 completed versus done requests 89 defined 41 list of, defined 339 modifying alternates 69 multiple 60 overriding 51, 71 previewing 144, 218 problem with responses 323 rejecting requests 89 response in sample application 75 reviewing alternates 69 roles and 92 serving as alternate 50, 68 approving requests 75, 89, 97 AP-Sample:Company form 216 AP-Sample:Lunch Scheduler form 215, 224 AP-Sample:Lunch-Detail form 215 AP-Sample:Lunch-Detail-Signatu form 216, 225 AP-Sample:Restaurant form 216 AP-Sample:Signature Authority form 216, 226 APW:Access Privileges form 310 APW:Approval Central form 312 APW:More Info Requests form 313 AR System administrator 339 AR System filters 158 AR System server starting manually UNIX 28 Windows 27 stopping manually UNIX 29 Windows 27 AR System server, installation notes 20 AR System User creating approval rules 153 modifying approval rules 153 overriding approvers 71 responding to More Information requests 63 reviewing answers to More Information requests 63
AR System User, alternate approvers defining for other approvers 70 ar.cfg 266 ar.conf 266 ar_apinstall 23 ARDBC plug-in 27 deadlocked server 323 arjoinfix 233 arstruct.h 265 Assigned To field 231 assigning administrator capabilities 125 alternate approvers 49, 66 approval requests 61 limited administration rights 84 override capabilities 211 audit trail of approval requests 85 authority process administrator and 84 signature 68 Auto-Approval Rules process instance ID, using 159 Auto-Approval rules checks 90 creating 160 defined 338, 339 example of 161 worksheet 245
B
BMC Remedy Alert 134 browsers, web 54 Business Time Holidays form configuring 137 described 315 More Information escalations 148 Business Time Workdays form described 315 More Information escalations 148 buttons Manage More Information 223 Show Approval Summary 224 Show Signature 224
356 Index
C
cancel at later level 340 cancelled 340 cancelling approval processes 222 category parameter 256 chained processes 105, 221, 235 complex 40 filters 214, 234 Change Management 20, 320 changing alternate approvers 69 processes 149 rules 205 checks auto approval 90 self approval 91 clients web 54 Windows User Tool 56 close approve 341 close reject 341 closed 341 command format 256 command parameter 256 commands, Approval Server Add-PGNA-Values 259 Add-Sig 258 Det-Approved 259 Det-Cancelled 259 Det-Error 260 Det-Rejected 260 MoreInfo-Return 261 New-Details 261 Rename-Form 262 Rename-Process 262 Sig-Approved 262 Sig-Cancelled 263 Sig-Notify 263 Sig-Notify-Change 264 Sig-Notify-State 264 Sig-Reassign 265 Sig-Rejected 265 Update-Config 265 compatibility matrix 20 complete versus done 89
completing processes 89 Completion Checks diagram of 103, 106 routing and 102 rules 104 Completion rules creating 188 defined 341 described 187 example of 188 worksheet 250 complex processes 40 components, Approval Server 120 configuring Approval Server 122 Approval Web without portmapper 30 Business Time Holidays form 137 connecting applications to Approval Server 230 conventions used in this manual, preface 17 Create Date field 231 creating actions for rules 157 alternate approvers 70 Approval Process 84 notifications 129 processes 87, 140 roles 208 rules 154 creating rules Auto-Approval rules 160 Completion 188 Get Authority 181 Get Authority Regular 183 Get Authority Self 185 Get Next Approver 170, 174 Prep Get Next Approver rules 165 Self Approval rules 162 Signature Accumulator 190 Statistical Override rules 193 Validate Approver 179 currency fields 156, 157 functions 157 current signature records 99
Index
357
D
daemon 25 debugging Approval Server 122 debug mode 266, 272 log file 124 default directories 334 defining actions for rules 157 alternate approvers 70, 209 notifications 129 roles 208 defining rules Approval Process Done 201 Auto-Approval 160 Completion 188 Get Authority 181 Get Authority Regular 183 Get Authority Self 185 Get Next Approver 170, 174 Prep Get Next Approver 165 Self Approval 162 Signature Accumulator 190 Statistical Override rules 193 Validate Approver 179 delegating authority 85 deleting processes 150 rules 206 designating alternate approvers 49, 66 designing processes 242 Detail records 85 Detail-Signature records 47 Det-Approved command 259 Det-Cancelled command 259 Det-Error command 260 Det-Rejected command 260 dialogs AP:Admin-DeleteVerify 270 AP:Admin-Rename 121, 271 AP:Admin-ServerSettings 127, 272 AP:Dtl-Sig-MoreInfoDialog 283 directory structure 334, 335 done versus complete 89 Done, Process 89
E
editing alternate approvers 69 processes 149 rules 205 email notifications 127, 129 defining 135 enabling notifications 127 entering rule information 156 errors approval 49 defined 342 process 104 escalations creating 275 enabling 127 More Information 148 signature 298 signature worksheets 243 events that trigger notifications 133 EXTERNAL keyword notification qualifications 287 Rule qualifications 305 Run If qualifications 305 Set Fields qualifications 308
F
feedback 37 field IDs 1 230 102 225 13191 232 536870920 221 7 231, 232 8 231 fields All must sign 171, 175, 209 Approval Workspace 221 One must sign 171, 175, 209 Reassign 48 Request 231 Request ID 230 Status 232
358 Index
filters AP-Sample:StartCostApproval 217 AP-Sample:StartLevelApproval 217 AP-Sample:StartOverdueApprov 218 New-Details command 234 specifying for rules 158 first approver list 169 first level of approvers 169 format of commands 256 forms AP:Administration 118, 234, 269 AP:Alternate 276 AP:Detail 85, 279 AP:Detail-Signature 232, 280 AP:Form 284 AP:More Information 86, 242, 285 AP:Notification 243, 286 AP:PreviewInfo 292 AP:Process Administrator 125, 211, 292, 293 AP:Process Definition 140, 242, 295 AP:Reserved Word 301 AP:Role 208, 301 AP:Rule Definition 154, 303 AP:Signature 86, 309 Application Pending 20, 256, 321 Approval Central 268 APW:Access Privileges 310 APW:Approval Central 312 APW:More Info Requests 313 Business Time Holidays 137, 315 Business Time Workdays 315 licensing for approval process 20 See also forms, Lunch Scheduler User 317 forms, Lunch Scheduler AP-Sample:Company 216 AP-Sample:Lunch Scheduler 215, 224 AP-Sample:Lunch-Detail 215 AP-Sample:Lunch-Detail-Signatu 216, 225 AP-Sample:Restaurant 216 AP-Sample:Signature Authority 216, 226 functions currency 157 date 157
G
Get Agreement application ad hoc process 74 approving requests 75 licensing sample users 226 parent-child hierarchy 227 reassigning requests 79 requesting items 74 requesting more information 77, 78 reviewing answers to More Information requests 80 statistical rules 199 Get Authority Regular rules creating 183 defined 344 described 104 example of 184 worksheet 250 Get Authority rules creating 181 defined 344 described 91 example of 182 worksheet 246 Get Authority Self rules creating 185 defined 344 described 91 example of 187 worksheet 246 Get Next Approver rules ad hoc process 113, 169 creating 170 defined 344 described 94, 168 example of 172 level process 169 parent-child process 168 rule-based process 170 worksheet 249 global approve 280 overrides 52, 72 reject 280 group (402) 347
Index
359
H
Hidden characteristic 232 Approval Central 231 hold defined 344 response to requests 96
I
ID, reserved 230, 231 inner join 232 installation notes 20 installer script, UNIX 23 installing Approval Server for Windows 21 Approval Web notes and 20 AR System server notes and 20 directory structure 334, 335 licensing Approval Server 321 troubleshooting 320
logging in User tool 56 web clients 54 Low Priority Notification worksheet 244 Lunch Scheduler application approval processes 216 chaining approval processes 221 forms 215 licensing sample users 226 overview 214 parent-child hierarchy 227 restarting approval processes 222 reviewing information 223 showing password field 225 showing signatures 224 showing summaries 224
M
Major Account Level Approval approval process 217 Manage More Information button 223 Management Cost Authorization approval process 217 Modified Date field 231 modifying alternate approvers 69 processes 149 rules 205 More Information defined 346 records 285 worksheet 242 More Information escalations notifications 148 setting parameters 148 worksheet 242 More Information requests entering information 62 responding to 63, 96 reviewing answers 63 reviewing answers in sample 80 using in sample application 77, 78 MoreInfo-Return command 261 multiple approvers 60
J
join forms, applications with Approval Server 230 join, inner 232
L
Last Modified By field 231 level approvers 169 defined 345 identifier 169 level process described 110 Get Next Approver rules 169 licensing approval server does not require purchasable license 20 before Approval Server installation 321 forms 20 sample users 226, 322 limiting administration rights 84 linking applications to Approval Server 230 lists first approver 169 signatures 224 log file, debugging and 123, 124
360 Index
multitenancy Add-Sig command 258 New-Details command 261 support added to approval server 16
P
Parameterized Get Next Approver rules ad hoc process 113, 169, 174 creating 174 defined 346 described 174 example of 177 rule-based process 170 worksheet 251 parameters 256 parent-child process described 108 Get Next Approver rules 168 sample applications and 227 Password field 225 passwords setting up for users 297 verifying 281 pending 347 performance issues with privileges 67 performing overrides 51 permissions change 209 connecting applications and 231 performance issues with privileges 67 portmapper 30 portmapper and Approval Web 30 preface conventions used in this manual section 17 related Remedy documents section 14 Prep Get Next Approver rules creating 165 defined 347 described 93 example of 217 worksheet 248 previewing approvers 144, 218, 292 previous Approval Server installation 320
N
new features 15 new signature 346 New-Details command 234, 261 multitenancy 261 Next Approver rules 93 Normal Priority Notification worksheet 243 notifications creating 274 email 127 enabling 127 escalation worksheets 243 examples of 115 methods 134 process administrators and 126 setting up 129 workflow 134, 230 workflow-based, enabling 235
O
One must sign field 171, 175, 209 Other, Set Fields value 158 Override Only Admin privileges 293 Override Only process administrators 85 override reject 346 overrides, Ad Hoc 142 overriding approvers 51 assigning capabilities 211 global 52, 72 process administrators and 84 single signatures 71
Index
361
process administrators adding alternate approvers 70 assigning capabilities 125 authority of 84 creating processes and rules 87 defined 84 delegating authority 85 described 43 Override Only 85 overriding approvals 71 responsibilities of 84 Specific Process 85 Process definition worksheet 242 Process Done rules 105 process instance ID, using with Auto-Approval rules 159, 160 Process, Set Fields value 158 processes chained 105 creating 140 deleting 150 designing worksheet 242 done versus complete 89 errors 104 modifying 149 restarting 222 rules and 87 types of 107 processing approval requests 46 product compatibility matrix 20 Purchasing@Work 320
Q
Query, Set Fields value 158
R
reassigning approval requests 48 requests in sample application 79 records active signature 99 current signature 99 Detail 85 Detail-Signature 47 reject response to requests 96
rejected 348 rejecting by another approver 89, 348 by later level 348 related Remedy documents in preface 14 relationships level approval process 110 parent-child approval process 108 roles and 92 rename, process 151 Rename-Form command 262 Rename-Process command 262 repeat interval 299 Request field 231 Request ID field 230, 231 requesters 41 requesting items in sample application 74 more information 48, 62 requests, approval audit trails 85 defined 338 diagram of 88 login list 55, 57 processing 46, 54, 119 reassigning 48 responding to 56, 96 sample application 73 specifying next approver 48 status of 47 viewing 46, 58 requests, More Information described 48 entering information 62 responding to 63 reviewing answers 63 reviewing answers in sample 80 using in sample application 77, 78 reserved ID 230, 231 responding to approval requests 56 More Information requests 63, 78 responses problem with 323 types of 96
362 Index
responsibilities of process administrators 84 restarting processes 222 restoring forms during installation 24 reviewing alternate approvers 69 approval requests 58 Lunch Scheduler application and 223 More Information responses 63 roles approver 92 creating 208 defined 348 versus relationships 92 routing, setting up for 84 RPC socket number 273 rule-based process described 114 example of 217 Get Next Approver rules 170 rules approval process and 87 completion 104 creating 154 deleting 206 filtering 203 modifying 205 stages, viewing 203 rules, types of Approval Process Done 201 Auto-Approval 159 Completion 187 Get Authority 91, 181 Get Authority Regular 104, 183 Get Authority Self 91, 185 Get Next Approver 94, 168, 174 Parameterized Get Next Approver 174 Prep Get Next Approver 93 Process Done 105 Self Check 90 Self-Approval 92 Signature Accumulator 190 Statistical Override rules 193 Validate Approver 94, 179, 323
rules, worksheets for Approval Process Done 253 Auto-Approval 245 Completion 250 Get Authority 246 Get Authority Regular 250 Get Authority Self 246 Get Next Approver 249, 251 Prep Get Next Approver 248 Self-Approval 247 Signature Accumulator 252 Statistical Override 252 Validate Approver 247 Run Process action 256 runtime, troubleshooting 323
S
sample Get Agreement application ad hoc process 74 approving requests 75 licensing sample users 226 More Information requests 77, 78, 80 parent-child hierarchy 227 reassigning requests 79 requesting items 74 statistical decision-making rules sample 196 sample Lunch Scheduler application approval processes 216 chaining approval processes 221 forms 215 licensing sample users 226 overview 214 parent-child hierarchy 227 restarting approval processes 222 reviewing information 223 showing password field 225 showing signatures 224 showing summaries 224 sample users, licensing 226, 322 Self Check approvals 89, 91 rules 90
Index
363
Self-Approval rules creating 162 defined 349 described 162 example of 164 overview 92 worksheet 247 server settings 272 configuring 122 serving as alternate approver 50, 68 Set Fields tab AP:Rule Definition form 157 assignment types 158 examples 159 setting up alternate approvers 70 approval routing 84 field values on forms 157 notifications 129 roles 208 setting up rules Approval Process Done 201 Approval Process Done worksheet 253 Auto-Approval Rules 159 Auto-Approval worksheet 245 Completion 188 Completion worksheet 250 Get Authority 181 Get Authority Regular 183 Get Authority Regular worksheet 250 Get Authority Self 185 Get Authority Self worksheet 246 Get Authority worksheet 246 Get Next Approver 170, 174 Get Next Approver worksheet 249, 251 Parameterized Get Next Approver 174 Parameterized Get Next Approver worksheet 251 Prep Get Next Approver 165 Prep Get Next Approver worksheet 248 Self-Approval 162 Self-Approval worksheet 247 Signature Accumulator 190 Signature Accumulator worksheet 252 Statistical Override rules 193
Statistical Override worksheet 252 Validate Approver 179 Validate Approver worksheet 247 Setup@Work 320 Short Description field 232 Show Approval Summary button 224 Show Signature button 224 Sig-Approved command 262 Sig-Cancelled command 263 signature active record 99 authority 68 current records 99, 189 escalations 298 escalations worksheets 243 line errors 49 line records 168, 171, 175 open (currently) 200 overriding single 71 record 349 Totals 100 weights 97 Signature Accumulator rules conceptual overview 99 creating 190 defined 349 example of 191 sample 200 weights 97 worksheet 252 Sig-Notify command 263 Sig-Notify-Change command 264 Sig-Notify-State command 264 Sig-Reassign command 265 Sig-Rejected command 265 single signature overrides 71 socket number 273 Special Overdue Approval approval process 217 Specific Process process administrator 85 SQL, Set Fields value 158 starting Approval Server manually 27 starting AR System server, manually UNIX 28 Windows 27
364 Index
statistical decision-making rules conceptual overview 97 sample 196 underlying workflow 199 Statistical Override rules conceptual overview 101 creating 193 defined 349 example of 195 sample 200 Total signature values 100 worksheet 252 status approval requests and 47 Approval Status 59 notifications, defining 130 Status field 232 Status field ID 7 231 stopping Approval Server manually 27 stopping AR System server, manually UNIX 29 Windows 27 Submitter field 231
U
uninstall 31 UNIX arjoinfix 233 daemon 25 default directories 334 directory structure 335 start command 28 Update-Config command 265 Urgent Priority Notification worksheet 243 URL Administration 119 Approval Central 54, 322 navigation links in applications, adding 239 User form 317 User tool logging in 56
V
Validate Approver rules approver cannot respond 323 creating 179 defined 350 described 94, 179 example of 180 worksheet 247 viewing alternate approvers 69 approval requests 46, 58 More Information responses 63
T
Total signature values 100 trails, audit, of approval requests 85 transferring requests 79 tree, directory 334, 335 triggering notifications 127 troubleshooting Application Pending form 321 Approval Web 322 approver cannot respond 323 ARDBC plug-in 323 deadlocked approval server 323 installation 320 licensing 321 runtime 323 sample applications 322
W
web clients 54 accessing Approval Server 119 creating approval rules 153 modifying approval rules 153 using 119 web document directory 273 weighting signatures with Signature Accumulator rules 97 Windows arjoinfix.exe 233 default directories 334 directory structure 334 installing Approval Server 21
Index
365
workflow notifications 134, 230 notifications, enabling 235 process instance ID, using 160 worksheets, process Low Priority Notification 244 More Information 242 Normal Priority Notification 243 Process definition 242 Urgent Priority Notification 243 worksheets, rule Approval Process Done 253 Auto-Approval 245 Completion 250 Get Authority 246 Get Authority Regular 250 Get Authority Self 246 Get Next Approver 249, 251 Prep Get Next Approver 248 Self-Approval 247 Signature Accumulator 252 Statistical Override 252 Validate Approver 247 write licenses 226
366 Index