Rmdy Approval4

Remedy Approval Server 4.
0
Users Guide for Windows and UNIX
19992000 by Remedy Corporation. All rights reserved.
This documentation may not be copied in whole or in
part without the prior written consent of Remedy
Corporation.
Remedy, the Remedy Corporation logo and design,
Action Request System, AR System, ARWeb,
Flashboards, Remedy Approval Server, Remedy
Purchasing@Work, Remedy SetUp@Work, and Remedy
Change Management are registered or other trademarks
of Remedy Corporation, Mountain View, CA, USA.
All other trademarks are the property of their respective
owners.
U.S. GOVERNMENT RIGHTS. Use, duplication, or
disclosure by the Government is subject to Remedy
Corporations commercial software license(s). If you are
the U.S. government, you agree that these written
materials are commercial computer software-related
documentation licensed pursuant to the terms of Remedy
Corporations commercial computer software license(s)
in accordance with 48 C.F.R. 12.212 of the Federal
Acquisition Regulations and its successors and 48 C.F.R.
227.7202-1 of the DoD FAR Supplement and its
successors. Unpublished rights are reserved under the
copyright laws of the United States.
Part Number: ARAS-400-UG-01
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
Related Remedy Documents . . . . . . . . . . . . . . . . . . . . . . . . xiv
Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . xiv
1 Understanding the Approval Process

The Basic Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
The Approval Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
The Remedy Approval Server. . . . . . . . . . . . . . . . . . . . . . . . 1-3
Common Experience Across Applications . . . . . . . . . . . . . . 1-3
Flexibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Notification plus Feedback . . . . . . . . . . . . . . . . . . . . . . 1-4
2 The Remedy Model for Approvals

Key Concepts of the Approval Server . . . . . . . . . . . . . . . . . . . . 2-2
The Approval Process . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Who Participates in the Approval Process . . . . . . . . . . . . . . 2-2
Acknowledging Approvals . . . . . . . . . . . . . . . . . . . . . . . 2-6
Where to Go Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
3 Working as an Approver
Processing an Approval Request . . . . . . . . . . . . . . . . . . . . . . 3-2
Viewing Approval Requests . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Performing Other Approval Actions . . . . . . . . . . . . . . . . . . . . . 3-3
Requesting More Information . . . . . . . . . . . . . . . . . . . . . 3-3
Reassigning an Approval Request . . . . . . . . . . . . . . . . . . 3-3
Specifying the Next Approver . . . . . . . . . . . . . . . . . . . . . 3-4
Handling Approval Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Table of Contents iii

Designating Alternate Approvers . . . . . . . . . . . . . . . . . . . . . . 3-4
Designating Alternate Approvers for Yourself . . . . . . . . . . . . . 3-5
Serving as an Alternate Approver . . . . . . . . . . . . . . . . . . . 3-5
Managing Alternate Approver Definitions . . . . . . . . . . . . . . . 3-6
Performing Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
4 Processing Approval Requests with Remedy User

Processing More Information Requests . . . . . . . . . . . . . . . . . . . 4-4
Reviewing Answers to More Information Requests . . . . . . . . . . 4-5
Responding to More Information Requests . . . . . . . . . . . . . . 4-5
Reassigning an Approval Request . . . . . . . . . . . . . . . . . . . 4-6
Specifying the Next Approver . . . . . . . . . . . . . . . . . . . . . 4-6
Processing as an Alternate Approver . . . . . . . . . . . . . . . . . . . . 4-7
Designating Alternate Approvers. . . . . . . . . . . . . . . . . . . . 4-7
Acting as an Alternate Approver . . . . . . . . . . . . . . . . . . . . 4-8
Managing Alternate Approver Definitions . . . . . . . . . . . . . . . 4-9
Additional Options for Process Administrators . . . . . . . . . . . . . . . 4-10
Defining Alternates for Others . . . . . . . . . . . . . . . . . . . . 4-10
Performing Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 4-10
5 Processing Approval Requests with ARWeb

Reassigning an Approval Request . . . . . . . . . . . . . . . . . . . 5-8
Using Alternate Approvers . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Designating Alternate Approvers. . . . . . . . . . . . . . . . . . . . 5-8
Acting as an Alternate Approver . . . . . . . . . . . . . . . . . . . . 5-9
Managing Alternate Approver Definitions . . . . . . . . . . . . . . 5-11
iv Table of Contents
6 Using a Sample Application
Using a Sample Application. . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Summary of Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
7 The Process Administrators Guide

The Process Administrator . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Process Administrator Responsibilities . . . . . . . . . . . . . . . . 7-2
Sharing Process Administration Authority. . . . . . . . . . . . . . . 7-2
Delegating Process Administration Capability . . . . . . . . . . . . 7-2
Key Features of the Approval Server . . . . . . . . . . . . . . . . . . . . 7-3
Approval Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Approval Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Common Rules and Operations . . . . . . . . . . . . . . . . . . . . . . 7-5
Self Check Rules - Preventing Unnecessary Routing . . . . . . . . . 7-7
Approver Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Next Approver Rules - Determining Who Is Next . . . . . . . . . . . 7-9
Approver Response - The Signature Line . . . . . . . . . . . . . . 7-12
Routing Completion Check - Whos Left? . . . . . . . . . . . . . . 7-13
Process Done Rules . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Summary of Common Process Elements . . . . . . . . . . . . . . 7-16
Approval Process Types . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Summary of Process Types . . . . . . . . . . . . . . . . . . . . . 7-23
Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24
8 Working with the Approval Server

Using the Approval Administration Interface . . . . . . . . . . . . . . . . 8-2
The Administration Control Panel . . . . . . . . . . . . . . . . . . . 8-2
The Administration Menu . . . . . . . . . . . . . . . . . . . . . . . 8-3
Setting Up Administrator Capabilities . . . . . . . . . . . . . . . . . . . . 8-6
Using Approval Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Defining the Events to Trigger Notifications . . . . . . . . . . . . . . 8-8
Defining an Approval Notification . . . . . . . . . . . . . . . . . . 8-10
Configuring Business Times . . . . . . . . . . . . . . . . . . . . . . . 8-16
Where to Go Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Table of Contents v
9 Defining an Approval Process
Using the Process Definition Form. . . . . . . . . . . . . . . . . . . . . . 9-2
Creating a Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Working with Existing Processes . . . . . . . . . . . . . . . . . . . . . . 9-9
Modifying Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Deleting Processes. . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Renaming Processes . . . . . . . . . . . . . . . . . . . . . . . . 9-11
10 Defining Approval Rules

The Rule Definition Form . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
The Rule Definition Form. . . . . . . . . . . . . . . . . . . . . . . 10-2
Using the Basic Tab on the Rule Definition Form . . . . . . . . . . 10-3
Using the Set Fields Tab on the Rule Definition Form . . . . . . . . 10-4
Working with Auto-Approval Rules . . . . . . . . . . . . . . . . . . . . . 10-5
Working with Self-Approval Rules . . . . . . . . . . . . . . . . . . . . . 10-7
Defining Self-Approval Rules. . . . . . . . . . . . . . . . . . . . . 10-8
Working with Prep Next Approver Rules . . . . . . . . . . . . . . . . . 10-10
Working with Get Next Approver Rules . . . . . . . . . . . . . . . . . 10-12
Working with a Parent Child Process . . . . . . . . . . . . . . . 10-12
Working with a Level Process . . . . . . . . . . . . . . . . . . . 10-12
Working with an Ad Hoc Process . . . . . . . . . . . . . . . . . 10-13
Working with a Rule-Based Process . . . . . . . . . . . . . . . . 10-13
Defining Basic Data for Get Next Approver Rules . . . . . . . . . 10-13
Working with Validate Approver Rules . . . . . . . . . . . . . . . . . . 10-17
Defining Validate Approver Rules . . . . . . . . . . . . . . . . . 10-18
Working with Get Authority Rules . . . . . . . . . . . . . . . . . . . . 10-20
Working with Get Authority Regular Rules . . . . . . . . . . . . . . . . 10-23
Working with Get Authority Self Rules . . . . . . . . . . . . . . . . . . 10-25
Working with Completion Rules . . . . . . . . . . . . . . . . . . . . . 10-28
Defining Routing Completion Rules . . . . . . . . . . . . . . . . 10-28
vi Table of Contents
Working with Approval Process Done Rules . . . . . . . . . . . . . . . 10-30
Defining Approval Process Done Rules . . . . . . . . . . . . . . . 10-30
Working with Existing Rules. . . . . . . . . . . . . . . . . . . . . . . . 10-32
Modifying Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33
Deleting Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33
11 Managing Users and Roles

Defining Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Defining Alternate Approvers . . . . . . . . . . . . . . . . . . . . . . . 11-4
Assigning Process Override Capability . . . . . . . . . . . . . . . . . . 11-5
12 Adding Approvals to Your Application

Connecting an Application to the Approval Server . . . . . . . . . . . . 12-2
Preparing Your Application for Approval Web . . . . . . . . . . . . . . . 12-6
13 Implementing Sample Application Features

Overview of Lunch Scheduler . . . . . . . . . . . . . . . . . . . . . . . 13-2
Key Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
AP-Sample:Lunch Scheduler . . . . . . . . . . . . . . . . . . . . 13-2
AP-Sample:Lunch-Detail . . . . . . . . . . . . . . . . . . . . . . 13-3
AP-Sample:Lunch-Detail-Signatu . . . . . . . . . . . . . . . . . . 13-3
AP-Sample:Company . . . . . . . . . . . . . . . . . . . . . . . . 13-3
AP-Sample:Restaurant . . . . . . . . . . . . . . . . . . . . . . . 13-3
AP-Sample:Signature Authority . . . . . . . . . . . . . . . . . . . 13-3
Sample Process Descriptions. . . . . . . . . . . . . . . . . . . . . . . 13-3
Management Cost Authorization . . . . . . . . . . . . . . . . . . 13-4
Major Account Level Approval. . . . . . . . . . . . . . . . . . . . 13-4
Special Overdue Approval. . . . . . . . . . . . . . . . . . . . . . 13-4
Chaining Approval Processes. . . . . . . . . . . . . . . . . . . . . . . 13-5
Using a Status Field in Chained Processes . . . . . . . . . . . . . 13-5
Flow Between Chained Processes . . . . . . . . . . . . . . . . . 13-5
Table of Contents vii

Restarting an Approval Process . . . . . . . . . . . . . . . . . . . . . . 13-6
Special Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
Show Summary and Signatures . . . . . . . . . . . . . . . . . . . 13-7
Show Password Field If Required . . . . . . . . . . . . . . . . . . 13-8
Recommended Technique: Menu of Valid Names . . . . . . . . . . 13-9
Sample Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Sample User Approval Authority . . . . . . . . . . . . . . . . . . 13-10
A Installation and Configuration

Installation Notes and Warnings . . . . . . . . . . . . . . . . . . . . . . .A-2
General Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-2
AR System Server Installation Notes . . . . . . . . . . . . . . . . .A-2
Approval Web Installation Notes . . . . . . . . . . . . . . . . . . . .A-2
Windows NT Installation . . . . . . . . . . . . . . . . . . . . . . . . . . .A-4
Windows NT Web Installation (Optional). . . . . . . . . . . . . . . . . . A-11
UNIX Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18
Preparing UNIX Servers for the Approval Server . . . . . . . . . . A-18
Installing the Approval Server on UNIX Servers . . . . . . . . . . . A-19
UNIX Web Installation (Optional) . . . . . . . . . . . . . . . . . . . . . A-22
Manually Starting and Stopping the Approval Server . . . . . . . . . . . A-23
ARWeb Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . A-24
Web Server Directory Permissions. . . . . . . . . . . . . . . . . . A-24
Using an AR System Server Without Portmapper . . . . . . . . . . . . . A-25
AR System Server Without Portmapper . . . . . . . . . . . . . . . A-25
Approval Server Configuration . . . . . . . . . . . . . . . . . . . . A-26
Approval Web Configuration . . . . . . . . . . . . . . . . . . . . . A-27
ARWeb 4.x Configuration . . . . . . . . . . . . . . . . . . . . . . A-27
Uninstalling the Approval Server . . . . . . . . . . . . . . . . . . . . . . A-28
Removing a Windows Installation . . . . . . . . . . . . . . . . . . A-28
Removing a UNIX Installation . . . . . . . . . . . . . . . . . . . . A-28
Where to Go Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28
viii Table of Contents

B Worksheets
Process Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
Defining a Process . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
More Information Escalations . . . . . . . . . . . . . . . . . . . . . B-2
Signature Escalations . . . . . . . . . . . . . . . . . . . . . . . . . B-3
Rule Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6
Auto-Approval Rules . . . . . . . . . . . . . . . . . . . . . . . . . B-7
Get Authority Self Rules . . . . . . . . . . . . . . . . . . . . . . . . B-7
Get Authority Rules . . . . . . . . . . . . . . . . . . . . . . . . . . B-8
Self-Approval Rules . . . . . . . . . . . . . . . . . . . . . . . . . . B-8
Validate Approver Rules. . . . . . . . . . . . . . . . . . . . . . . . B-8
Prep Next Approver Rules. . . . . . . . . . . . . . . . . . . . . . . B-9
Get Next Approver Rules . . . . . . . . . . . . . . . . . . . . . . . B-9
Get Authority Regular Rules . . . . . . . . . . . . . . . . . . . . B-10
Completion Rules . . . . . . . . . . . . . . . . . . . . . . . . . . B-10
Approval Process Done Rules . . . . . . . . . . . . . . . . . . . B-10
C Application Commands
Basic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
Specific Approval Server Commands . . . . . . . . . . . . . . . . . . . . C-4
Add-Sig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
Det-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
Det-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
Det-Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
Det-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
MoreInfo-Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
New-Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
Rename-Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7
Rename-Process . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7
Sig-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-7
Sig-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
Sig-Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
Sig-Notify-Change. . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
Sig-Notify-State . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-9
Table of Contents ix
Sig-Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-9
Sig-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10
Update-Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10
D Approval Forms
Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-2
AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . .D-3
AP:Alternate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-9
AP:Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-11
AP:Detail-Signature . . . . . . . . . . . . . . . . . . . . . . . . . D-12
AP:Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-15
AP:More Information . . . . . . . . . . . . . . . . . . . . . . . . . D-16
AP:Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-17
AP:Process Administrator . . . . . . . . . . . . . . . . . . . . . . D-20
AP:Process Definition . . . . . . . . . . . . . . . . . . . . . . . . D-21
AP:Reserved Word. . . . . . . . . . . . . . . . . . . . . . . . . . D-26
AP:Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-26
AP:Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . D-27
AP:Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-30
Business Time Holidays . . . . . . . . . . . . . . . . . . . . . . . D-31
Business Time Workdays . . . . . . . . . . . . . . . . . . . . . . D-32
User Form xxx . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-33
E Troubleshooting
Installation Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . .E-2
Previous Approval Server Installations . . . . . . . . . . . . . . . . .E-2
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .E-2
Application Pending Form . . . . . . . . . . . . . . . . . . . . . . .E-2
Approval Web Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . .E-3
The Approval Central URL . . . . . . . . . . . . . . . . . . . . . . .E-3
Browser Buttons Log Out User. . . . . . . . . . . . . . . . . . . . .E-3
Cannot Display Approval Web Pages . . . . . . . . . . . . . . . . .E-3
Missing Tabs in Netscape . . . . . . . . . . . . . . . . . . . . . . .E-3
Sample Application Concerns . . . . . . . . . . . . . . . . . . . . . . . .E-3
Sample Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . .E-3
x Table of Contents
Miscellaneous Runtime Concerns . . . . . . . . . . . . . . . . . . . . . E-4
Approver Receives Request but Cannot Respond . . . . . . . . . . E-4
Approval Server Wont Start Up With Oracle 8.0.x . . . . . . . . . . E-4
F Installation Directory Structures

Default Installation Directories . . . . . . . . . . . . . . . . . . . . . . . F-2
Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-2
UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-2
Directory Structure for Windows Installations . . . . . . . . . . . . . . . . F-2
Approval Server 4.x Files for Windows . . . . . . . . . . . . . . . . F-2
Approval Web Files for Windows ARWeb 4.x . . . . . . . . . . . . . F-4
Approval Web Files for Windows ARWeb 3.x . . . . . . . . . . . . F-11
Directory Structure for UNIX Installations . . . . . . . . . . . . . . . . . F-20
Approval Server 4.x Files for UNIX . . . . . . . . . . . . . . . . . F-20
Approval Web Files for UNIX ARWeb 4.x . . . . . . . . . . . . . . F-22
Approval Web for UNIX ARWeb 3.x . . . . . . . . . . . . . . . . . F-29
Glossary
Index
Table of Contents xi
xii Table of Contents
Preface
Audience
This 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
Remedy Approval Server.
Note The Approval Server Process Administrator is not the same as your Remedy
Action Request System Administrator. Refer to Chapter 7, The Process Administrators
Guide for a discussion of the Process Administrators responsibilities.
This guide assumes you are familiar with the 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 NT and UNIX Approval
Server forms and workflow, and assumes you are familiar with the environment in
which you install the software.
Note Refer to Appendix A, Installation and Configuration, for instructions on how to install
Action Request System.
Preface xiii
Related Remedy Documents
Title Description Audience Format

Action Request System Concepts Overview of the AR System architecture and Everyone Print and
Guide features with in-depth examples; information PDF
on other Remedy products
Action Request System Workflow Procedures for creating and modifying an AR Administrators Print and
Administrators Guide System application for tracking data and PDF
processes
Action Request System Server Server administration topics on configuring Administrators Print and
Administrators Guide servers, optimizing performance, and PDF
maintaining the AR System; technical essays
Unless otherwise noted, online documentation is available in Adobe Acrobat (PDF) format on Remedy product installation CDs and on
the Remedy Customer Support web site.
Conventions Used in This Manual
bold Indicates a new or important term.

Example: filters
italic Indicates a reference to another manual.

Example: See the Action Request System Concepts Guide.
Italic type is also used for emphasis.
Example: All users will have access.
courier Indicates computer output and names of various infrastructure

components (such as files, directories, machines, and
underlying data structures).
Example: # Remedy AR System Daemons
<italic_courier> Indicates a variable directory, file name, or string that users

replace with the actual directory, file name, or string.
Example: <install_directory>
bold courier Indicates data to be entered by the user.

Example: Type <install_directory>/etc/ar.
Indicates a series of menu selections.

Example: Choose File Export Definitions.
Used in the left margin to indicate a step-by-step procedure.
xiv Preface
1 Understanding the Approval
Process Chapter
This chapter is written for all users and administrators of the Remedy Approval
Server. This chapter introduces key concepts by answering these questions:
The Basic Approval
The Approval Process
The Remedy Approval Server
Note Refer to Appendix A, Installation and Configuration, for instructions on how to install
the Approval Server.
1-1
The Basic Approval
An approval indicates agreement or rejection of a request. In business, approvals
are generally signatures of key individuals, recorded for the purposes of
providing an audit trail or proof of authenticity.
Approval Examples
When you ask your boss to sign for your vacation or a new computer, you are requesting
an approval. Your signed check is an approval of the transfer of funds from your account,
and your signed lease is an approval for living under the terms of your landlord.
An approval is always a means to an end. A signature in the examples above

enables another activity or process: a paid vacation, a computer purchase, a funds
transfer, or promise of living conditions. The Approval Server is a means to
approving AR System workflow.

An approval process is the set of rules and procedures for selecting people to
review and authorize a request in the proper manner.
A process must have rules to ensure all required approvals occur, no erroneous
approvals occur, and sufficient authority is present to enable approval.
A process must have procedures to route an approved request to the next
approver, to stop routing a rejected request, and to notify a person when a
response is required.
Every approval requires a process to obtain appropriate signatures, although
sometimes the process or signatures are not obvious. For example, even if
everyone in the company is automatically reimbursed for up to $25 in office
supplies, there is a hidden process with implied signatures that are not actually
demanded. The Approval Server handles these hidden processes as well as those
requiring traditional routing to multiple people for sign off.
In the business world, approval processes rarely require only one persons
approval. Business processes often require many people to sign off in order of
their chain of command. Some businesses route approvals to more than one
department at the same time. All business processes need to cope with
substitutions for unavailable people, holidays, or other complications.
A given request may require one process for completion, or require several
processes that work with each other. Often the appearance of a single operation
involves multiple approvals.
1-2 Chapter 1 Understanding the Approval Process

One Request Can Generate Multiple Approval Processes
Imagine an office employee requesting a faster personal computer. The request to purchase
a new computer has to be approved by the employees manager. If the manager approves,
a separate MIS department approval process then determines the model of computer to buy.
These approval processes are separate, but both must be completed successfully for a
computer to be delivered.
Approval processes must be able to handle a variety of situations without failing.

Imagine a process that skips required people, or gets routed to a person without
authority, or a process that cannot cope with vacationing persons and other
anomalies. When an approval process fails, so does the attached activity. The
funds are not transferred, the apartment is leased to someone else, or the
computer is never delivered.
The Remedy Approval Server

The Remedy Approval Server is a self-contained, shared module that can be
attached to any AR System application. Multiple Approval Server licenses can
reside on one AR System server.
When an AR System application triggers an approval process, the Approval
Server routes a request to collect signatures within 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.
Common Experience Across Applications

With the Approval Server, there is no need to build custom workflow or separate
solutions for each application. All processes can share the same approval engine.
The Approval Server lets users learn one approval engine for all applications, and
it lets administrators swiftly implement one common solution.
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?
The Remedy Approval Server 1-3

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.
Notification plus Feedback

Although the system is named an Approval Server, it is really more than an
application that asks for approvals. You can use the Approval Server for any
process where there is a need for agreement or acknowledgment from others.
Agreement or Acknowledgment
Imagine you had to turn off an important system for maintenance. It would be helpful to
send out approvals to affected customers in advance. While the customers are not really
approving the downtime, their approval is an acknowledgment of the coming change
and the fact they are prepared for it. If they reject the change, those customers are
indicating that they are not prepared, and may need additional assistance.
An alternative process could be a simple AR System notification. There is no

feedback loop defined with notifications, however, so it is difficult to know if
everyone has seen the notice and is ready for the upcoming event.
The Approval Server adds notifications to feedback loops, ensuring your
workflow has been seen and approved by all the relevant parties.
1-4 Chapter 1 Understanding the Approval Process

2 The Remedy Model for
Approvals Chapter
This chapter provides an overview of the Approval Serverfrom approach and

key concepts through the interaction of both end-users and administrators.
Understanding these concepts is valuable to both approvers and administrators:
Key Concepts of the Approval Server
Where to Go Next
2-1
Key Concepts of the Approval Server
An approval requires a process for people to acknowledge. This chapter discusses
process, the people, and the acknowledgment.

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

Three kinds of people are involved in the approval process: those requesting
approval, those approving requests, and process administrators who set up and
modify the Approval Server configuration.
Most approval processes are transparent to the requester, who therefore does not
need to understand the Approval Server. This manual is written for approvers
and process administrators.
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.
2-2 Chapter 2 The Remedy Model for Approvals

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 may
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 reimburse-
ment 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.
Who Participates in the Approval Process 2-3

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
may 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.
Note An Approval Server Process Administrator is not the same as your Remedy Action
Request System Administrator. Refer to Chapter 7, The Process Administrators Guide
for an explanation of the Process Administrators responsibilities.
Who Participates in the Approval Process 2-5

Acknowledging Approvals
The Approval Server has three methods to allow AR system users who are not
approvers to track, or interact with, an approval process.
Notification
For every stage of the approval process, AR System notifications can be defined
to inform interested parties of the status of an approval request.
More Information Requests

An approver who has questions can send a more information request to the
requestor (or any other AR System user). More Information requests and their
responses are handled by the Approval Server.
Audit Trail
All activity within the system is recorded within the Detail Record. The
AR System captures approver activity, the time an activity occurred, and what
that activity was. This allows you to track the progress of the entry and see which
activity was performed at each stage.
Where to Go Next
Now that you understand the basic concepts of the AR System Approval Server,
you can review the following chapters covering approvers, installation and
process administrators
Chapter 3 through Chapter 6 contain concepts, procedures, and examples for
approvers.
Chapter 7 and later contain information for Approval Server Process
Administrators.
Appendix A contains installation instructions for AR System administrators.

3 Working as an Approver Chapter
This chapter discusses the approval process as it pertains to approvers. It covers

the following topics:
Processing an Approval Request
Viewing Approval Requests
Performing Other Approval Actions
Handling Approval Errors
Designating Alternate Approvers
Performing Overrides
Chapter 4 and Chapter 5 cover procedures for acting on approvals.
3-1
Approvals typically follow this sequence.
1. Someone submits a request that requires your approval.
2. You receive notification of the approval request.
3. You review the approval request and take one of the following actions:
If the request appears to be in order, you can approve it.
If you need more information, you can enter a question or comment for the
Approval Server to route to the requester or other individual.
If the request appears unacceptable you can reject it. Rejection ends the process
for this request.
If you feel that you are not the appropriate person to approve the request, you
can reassign it.
For procedural information with Remedy User, see Processing an Approval
Request on page 4-2. For procedures using ARWeb, see Processing an Approval
Request on page 5-2.
Viewing Approval Requests

The Approval Central form is the primary form for approvers. Approval Central
lets you view approval request and More Information requests. Approval Central
allows you to display your own requests, or the requests for which you can
respond as an alternate for someone else. Approval Central can be used from the
web if your AR System is configured with ARWeb.
Figure 3-1 The Approval Central Form
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
3-2 Chapter 3 Working as an Approver

request, or if you want to verify the status of a current approval request that you
have already approved.

For some approval requests, you may need to perform additional actions such as
the following:
Requesting More Information
Reassigning an Approval Request
Specifying the Next Approver

Asking for clarification is more friendly than rejecting a request for which you
have insufficient knowledge. For example, you may want clarification of dates or
other details. Within the Approval Server you can create a More Information
request before acting on an approval request.
Note A More Information request creates an independently routed AR System form,

separate from the original approval request.
As an approver, you can use the More Information request to ask a question
regarding the original request. The original request then pauses until you respond
to it. Others can see that the request is paused in a More Information status.
Your response to the original approval is independent from the More Information
routing. You never have to wait for the More Information answer. However, if you
do approve or reject the original approval request, the Approval Server
immediately closes your outstanding More Information request(s).
For procedural information, see Processing More Information Requests on
page 4-4. For procedures using ARWeb, see Requesting More Information on
page 5-6.

If you feel you are not the correct person to act on an approval request, many
processes allow you to reassign a request to a different approver. In such cases, a
Reassign field is displayed on the approval form. When you reassign an approval
request, your obligation to act on it ends.
Performing Other Approval Actions 3-3

For procedural information, see Reassigning an Approval Request on page 4-6.
For procedures using ARWeb, see Reassigning an Approval Request on
page 5-8.

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

If you enter an invalid name when you specify the next approver, a properly
designed process generates a signature line error. The approval process stops with
an error status until you correct the error by specifying a valid next approver.
Note Errors from an improperly designed approval process are not correctable by an
approver. Process administrators can refer to Get Next Approver - Automatically on
page 7-10, for information to ensure a process validates the next approver properly.

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

Designating Alternate Approvers for Yourself
If you will be unavailable for approving processes, you can designate other
persons to fill in for you as alternate approvers to prevent delays in the approval
process.
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 only your vacation
requests but not your purchase requisitions.
Note If your alternate designates an alternate, authority to sign your approvals is not
passed on. Only the specific person you designate can act as your alternate.
Alternate Authority Is Not Transferable
Violet is out of the office for a week and designates Larry as her alternate. Larry departs on
a surprise business trip, and designates Jack as his alternate. Jack does not have signature
authority for Violets requests. Jack cannot see Violets requests.
For procedural information, see Designating Alternate Approvers on page 4-7.

For procedures using ARWeb, see Designating Alternate Approvers on
page 5-8.
Serving as an Alternate Approver

If you have been designated as an alternate approver, you have signature rights
and responsibilities identical to those of the original approver for as long as you
serve as an alternate.
Your authority as an alternate approver exists for a specific time period. Your
authority can be defined for all processes, or a specific process.
Alternate Approver Scenario
Jack goes out of town to a trade show August 18. Jack designates Samantha as alternate
for all his approval processes from August 15. However, from August 68 Samantha is
limited to acting as alternate for only the office supply approval process, because the
Designating Alternate Approvers for Yourself 3-5

district manager Larry is going to be onsite acting as Jacks alternate for Jacks other
processes.
When you have been designated as an alternate, you see and respond to
approvals in the same manner as when you are a normal approver, but the system
knows you are acting as another person. The Approval Server shows you only
approval requests for one person at a time.
Acting As an Alternate
The Approval Server reinforces the separate identities Larry can act as, 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 3-2. For specific procedural information about serving as an
alternate, see Acting as an Alternate Approver on page 4-8. For procedures
using ARWeb, see Acting as an Alternate Approver on page 5-9.
Managing Alternate Approver Definitions

Use AP:Alternate to designate (create), verify, and modify alternate approver
information. For example, on this form you can create a new alternate, change an
alternate to someone else, modify the time period during which an alternate will
serve, or cancel an alternate so this person can no longer approve requests in your
name.
Note Although an approver uses the Approval Central form when acting as an alternate,
you must use the AP:Alternate form to designate and change information regarding
alternate approvers.
For procedural information, see Managing Alternate Approver Definitions on

page 4-9. For procedures using ARWeb, see Managing Alternate Approver
Definitions on page 5-11.

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.
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
There is also an advanced global override. This 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 on overrides, see Additional Options for Process

Administrators on page 4-10.
Performing Overrides 3-7

4 Processing Approval Requests
with Remedy User Chapter
This chapter covers the following procedures for processing approvals with the
Remedy User tool:
Processing More Information Requests
Processing as an Alternate Approver
Additional Options for Process Administrators
Note For procedures using ARWeb, refer to Chapter 5.
4-1
The following procedure outlines the basic steps for processing an approval
request. For information about additional approval actions you may need to
perform, refer to Performing Other Approval Actions on page 4-5.
Responding to Your Own Approval Requests

1. From Remedy User, log on to the appropriate AR System server.
2. Select File Open.
The Open dialog box appears.
3. From the list of forms, choose the Approval Central form and click OK.
The Approval Central form appears, as shown in Figure 4-1.
Action
Buttons
Figure 4-1 The Approval Central Form
4. From the Application list, select the application for which you are processing an
approval.
Note While most of the fields are optional, you must select an application before you click
the View Approvals action button.
5. (Optional) Enter the appropriate ID in the Request field to display a specific

approval request.
6. (Optional) Select a status from the Approval Status field menu list.
You can use the Approval Status field to display only approval requests with a
specific status. If you leave the Approval Status field blank, all your approvals are
displayed.
4-2 Chapter 4 Processing Approval Requests with Remedy User

7. Verify the option button setting for Acting As: Myself.
If you wanted to act in a different capacity than yourself, you would select
otherwise from this option button.
8. Click the View Approvals action button to view the requests you must approve.
This action button opens another form with a list of approval requests awaiting
your signature, such as shown in Figure 4-2.
Figure 4-2 List of Approval Requests
9. Select the request you want to respond to.

10. From the Approval Status menu list, select the type of response you want to give
the request.
For example, to approve the request, select Approved.
Processing an Approval Request 4-3

11. Add comments to the Comments field if necessary.
12. Click Save to submit the response.
Warning There is no undo when you respond to a request. Once you respond to a
request, you do not have any opportunity to change your mind.
If you do not want to respond with approval or rejection, you can ask for more
information, as shown in the following procedure.
Processing More Information Requests

The following procedures outline the basic steps for requesting more information
and responding to others More Information requests.

Use the following procedures to request more information before you respond to
an approval request. For conceptual information, see Requesting More
Information on page 3-3.
Requesting More Information About an Approval Request

1. Open the approval request. See Processing an Approval Request on page 4-2 for
the procedure.
2. Click Manage More Information. The More Information form appears.
Figure 4-3 More Information Request Form
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.
Warning This must be one persons exact AR System login ID.
4. In the Question field, enter your question or a description of the information you
need.
5. Click Save.
The Approval Status for the approval request automatically changes to reflect
your request for more information.
Reviewing Answers to More Information Requests

To view the responses to your More Information request, open the More
Information diary field in the approval form.
Responding to More Information Requests

Use the following procedures to respond when someone asks you for more
information regarding an approval.
Responding to a Request for More Information

Use this procedure to respond to a request for more information.
1. In the Approval Central form, click My More Information Requests.
A list of More Information requests is displayed.
2. In the Response field for each request, enter your response to the information in
the Question field.
3. Click Save.
The status of the request will automatically change to Completed.
Note You cannot respond to a More Information request from a notification window.

Some approval requests can require other actions such as reassigning an approval
request, or specifying the next approver. The following procedures provide
instructions for these actions.
Note Approval Application Search functionality is available only when an application is

specifically written to enable it.
Reviewing Answers to More Information Requests 4-5

Perform the following procedure if you must reassign an approval request. For
conceptual information, see Reassigning an Approval Request on page 3-3.

the procedure.
2. In the Reassign To field of the approval request, enter the name of the approver to
whom you want to reassign the request.
3. Click Save.

With some processes, approvers can or must specify the next approver. For
conceptual information, see Specifying the Next Approver on page 3-4.
Use the following procedure to specify the next approvers for a request.

the procedure.
2. In the Next Approvers field, enter the names of the next approvers for the request.
Warning This must be one or more exact AR System login IDs.
To specify multiple approvers, separate each name with a semicolon (;). If you
choose to specify multiple approvers, determine the appropriate option for the If
Multiple Approvers field:
To allow the request to be approved by a single signature, select One Must Sign.
To require all specified approvers to sign for the request to be approved, select
All Must Sign.
To use the default process setting for multiple approvers, leave this field blank.
3. Click Save.

Processing as an Alternate Approver
The following sections provide instructions for designating alternate approvers
and for serving as an alternate approver. For conceptual information, refer to
Designating Alternate Approvers on page 3-4.

Use the following procedure to create an alternate approver for yourself. If you
want multiple alternates, repeat this procedure for each alternate.
Designating an Alternate Approver

1. Log on to Remedy User.
2. Open the AP:Alternate form in New mode.
The Alternate form is displayed in New mode, as shown in Figure 4-4.
Figure 4-4 AP:Alternate Form
3. In the Alternate field, enter the name of the individual you want to designate as
an alternate.
4. In the Covering field, select the process for which you want the alternate to have
your signature authority.
To authorize all processes for which you have signature authority, select All.
To authorize a specific process, select Specific Processes, and then select a
process from the Process list. The drop-down list is not available until you
select Specific Processes.
Processing as an Alternate Approver 4-7

5. Specify the duration you want the alternate to act on your behalf by using the
Start Date and End Date fields.
6. To prevent notifications from being sent to the alternate for each new approval,
select No from the Notify Alternate list.
This setting can guarantee no notification is sent, but other system settings can
prevent notifications even if this setting is active.
7. Click Save.
Note Use this form to assign one alternate to one or all processes. If you want to
designate one alternate for multiple processes, but not all, you must repeat this procedure
for each process. If you want to designate multiple alternates for one process, repeat this
procedure for each alternate.
Acting as an Alternate Approver

If you are serving as an alternate approver, you have the same signature authority
as the approver you represent, regardless of your normal authority. The steps for
processing an approval request as an alternate are the same as for the original
approver; however, when you act on an approval request, you must identify
yourself as an alternate.
Identifying Yourself as an Alternate Approver

1. From the Application list of the Approval Central form, select the application for
which you want to approve requests.
2. In the Acting As: field, select Alternate.
The Current Approver and Process fields are enabled, as shown in Figure 4-5.
Figure 4-5 Alternate Identification
3. In the Current Approver field, enter the name of the person for whom you are
acting as the alternate approver.

4. From the Process list, select the process for which you are acting as the alternate
approver.
You can leave this field blank if you are the alternate for all processes.
5. Click View Approvals.

If you must review and modify information about an alternate approver, use the
following procedure.
Viewing the Record for an Alternate Approver

1. Open the AP:Alternate form in Search mode.
The AP:Alternate form appears.
2. In the For field, enter your name (or the name of the approver designated as your
alternate).
3. To narrow your search, fill in any additional fields on the form.
You can also create a more detailed search by clicking Advanced in the upper-
right corner.
4. Click Search.
A list of alternates that match your search criteria appears.
5. Select an alternate from the list to view the record for that alternate.
Modifying the Record for an Alternate Approver

If the circumstances for an alternate approver change, you can modify the record
for that approver by performing the following procedure.
1. Search the AP:Alternate form for the alternate whose record you want to change
according to the previous procedure.
2. Enter the desired changes.
To change the processes for which the alternate will have your signature
authority, make the appropriate selections in the Covering and Processes fields.
To change the dates on which the alternate will serve in your place, select the
appropriate dates in the Start Date and End Date fields.
To cancel the alternate, click Cancel Alternate.
3. Click Save to save your changes.
Managing Alternate Approver Definitions 4-9

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

Defining Alternate Approvers for Other Approvers
As process administrator you can define alternates for any approver within any
process where you have process administrator authority.
1. Create an alternate. Refer to Designating an Alternate Approver on page 4-7 for
the procedure.
2. In the For field, type the AR System user ID of the person this alternate will be
substituting for.
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, refer to Performing Overrides on page 3-7.
To specify an override in an approval process, perform the following steps.
Performing an Override to a Single Signature

which you want to perform an override.
2. In the Acting As: field, select either Override or Global Override.
If you select Override, the User and Process fields are enabled. Continue with
step 3.
If you select Global Override, only the Process field is enabled. Skip step 3 and
continue with step 4.
3. In the User field, enter the name of the approver whose signature authority you
want to override.
4. From the Process list, select the process for which you are performing the
override.
You can leave this field blank if you have override capability for all processes.

A list of pending approvals is displayed.
6. Select a request and open its Detail Signature form.
7. Change the status of the request, for example to Approved or Rejected.
8. Click Save to save your override.
Performing a Global Override to an Entire Process

Global overrides include approving or rejecting a request regardless of any
response by normal approvers.
which you want to perform an override.
2. In the Acting As field, select Global Override.
The Process field is enabled.
3. From the Process list, select the process for which you are performing the
override.
A list of pending process Detail Records appears.
5. Select a Detail Record and open it.
6. Click Global Approve or Global Reject.
7. Click Save to record your Global Override.
Performing Overrides 4-11

5 Processing Approval Requests
with ARWeb Chapter
This chapter covers the following procedures for processing approvals with
ARWeb.
Using Alternate Approvers
Note The ARWeb interface allows approvers to process approval requests from a web
browser. Process Administrators must use Remedy Administrator and Remedy User to
configure approval processes and perform overrides.
5-1
The following procedure outlines the basic steps for processing an approval
request using ARWeb. For information about additional approval actions you
may need to perform, refer to Performing Other Approval Actions on page 5-6.
Warning Use only the Approval Web links and buttons to navigate within ARWeb. You can
log out of ARWeb unintentionally if you use the Back or Forward buttons of your web
browser.

1. Launch your web browser and type in the URL for your Approval Server.
Refer to your AR System Administrator for the exact URL of Approval Web. For
example, with a machine name of acme, the Approval Server URL appears as
follows:
http://acme/esapps/approval/appstart.html
The Approval Central screen appears.
Figure 5-1 Approval Central for Approval Web
2. Click Log In at the top right of the screen.
5-2 Chapter 5 Processing Approval Requests with ARWeb

The Log In window appears. Log in to the Approval Server.
Figure 5-2 Log In to the Approval Server
3. Click a tab at the top of the main window to select an AR System application.
Approval Web displays the list of pending approval requests within that
application.
Figure 5-3 Displaying Requests Waiting for Your Approval
4. For each request, select the appropriate response: approve, reject, or no action.
5. Click Save when you have completed the entire page of requests.
You do not have to click Save after each response.
Warning There is no undo when you respond to a request. Once you respond to a
request, you do not have any opportunity to change your mind.
6. Enter your AR System login password if required.

The presence of the Password field does not mean all processes require a
password. The Password field appears for all processes in Approval Web even if
only one actually requires a password.

Reviewing an Approval Request
These steps require you to be logged in and examining your approvals as described in the
previous procedure Processing an Approval Request.
1. Click the Approval Status column entry for the request you want to examine.
For example, in Figure 5-3 you would click the word Pending for any of the approval requests.
The request details form appears.
Figure 5-4 Reviewing the Details of an Approval Request

Approve and Reject buttons appear on the control pane on the left side of the
browser window while reviewing status with Approval Web.
Figure 5-5 Command Pane While Viewing Request Details
2. Click the Approve or Reject button to respond to the request, or if you make
changes to the request, click Submit to save your changes.
A Modify Results message appears to display result of your action.
Note You do not have to click Submit if you use the command pane to approve or reject the
displayed request.
3. Click a button in the control pane to return to another view.

Home displays the welcome screen.
Approval List displays the status of all your current approval requests.
Help opens a new browser window to display online help.
Approve or Reject buttons save your response for the current approval request.
These buttons do nothing when you are viewing a Modify Results message.
View displays a list of your More Information requests.
Create displays a form to make a new More Information request as described
in the Requesting More Information section that follows.

Some approval requests can require other actions, such as requesting more
information, reassigning, or specifying the next approver. The following
procedures provide instructions for additional approver actions.

Use the following procedure to request more information before approving a
request. For conceptual information, see Requesting More Information on
page 3-3.
Requesting More Information About an Approval Request

1. Open the Details of the approval request, as shown in Reviewing an Approval
2. Click Create in the control pane to create a More Information request.
The More Information form appears.
Figure 5-6 Creating a More Information Request
3. In the To field, type the AR System login ID of the person you want to ask a
question.
4. In the Request field, type your question for this person.
5. Click Submit to save your More Information request.
The Approval Server routes your request to the person in the To field.

Viewing and Responding to Requests for More Information
Use this procedure to display the More Information requests directed to you.
1. Log in to the Approval Server as shown in Processing an Approval Request on
page 5-2.
2. Click View More Information in the control pane.
A list of your More Information requests appears.
Figure 5-7 Displaying Your More Information Requests
3. Click on your name for the More Information request you want to respond to.
The More Information request form opens.
Figure 5-8 Responding to a More Information Request
4. Type your answer in the Response field.

5. Click Submit to save your changes.
The Approval Server routes your response back to the More Information
requester.
Requesting More Information 5-7

Perform the following procedure if you must reassign an approval request. For
conceptual information, see Reassigning an Approval Request on page 3-3.

1. Open the Details of the approval request as shown in Reviewing an Approval
2. In the Reassign To field, type the AR System login name for the approver to
receive this approval request.
Type the name of a

new approver
Figure 5-9 Reassigning an Approval Request
3. Click Submit to save your change.

The Approval Server routes the request to the reassigned approver.
Using Alternate Approvers

The following sections provide instructions for designating alternate approvers
and for serving as an alternate approver. For conceptual information, refer to
Designating Alternate Approvers on page 3-4.

Use the following procedure to create an alternate approver for yourself. If you
want multiple alternates, repeat this procedure for each alternate.
Designating an Alternate Approver

1. Log in to ARWeb as shown in Processing an Approval Request on page 5-2.
2. Under Alternates in the control pane, click Create.

The Create Alternate Record form appears.
Figure 5-10 Creating an Alternate
3. In the Alternate field, type the AR System login name for the person to designate
as your alternate.
4. Use the Start Date and End Date fields to specify the time frame in which you
want the alternate to act on your behalf.
5. In the Covering field, select the process for which you want the alternate to have
your signature authority.
To authorize all processes for which you have signature authority, select All
from the pull-down menu.
To authorize a specific process, select Specific Processes from the pull-down
menu, and then select a process from the Process pull-down menu.
6. Select No from the Notify Alternate list if you want to prevent notifications from
being sent to the alternate for each new approval.
Acting as an Alternate Approver

If you are serving as an alternate approver, you have the same signature authority
as the approver for whom you are serving. The steps for processing an approval
request as an alternate are the same as for the original approver; however, when
you act on an approval request, you must identify yourself as an alternate
approver.
Acting as an Alternate Approver 5-9

Identifying Yourself as an Alternate Approver
Click GO
to Act as an Alternate
Figure 5-11 Acting as an Alternate
2. Click GO to start acting as an alternate approver.

The Alternate selection form appears.
Enter Login ID
of Alternate
Figure 5-12 Entering an Alternate Login ID to Act As
3. In the Acting As field, type the AR System login name of the person for whom
you are acting as alternate.
4. If the radio button does not change, click the radio button to change from Myself
to Acting As.
5. Click Apply to log in as an alternate approver.
The welcome screen appears. You can now approve requests with the signature
authority of the person who designated you as alternate.
Person You Are Pretending to be Your Login ID
Figure 5-13 Identifying Your Current Signature Authority

Use the following procedure to review or modify information about an alternate
approver.
Viewing the Record for an Alternate Approver

2. Under Alternate in the control pane on the left, click View.
3. The list of alternate records appears.
Figure 5-14 Reviewing Your Designated Alternates
Modifying the Record for an Alternate Approver

If the circumstances for an alternate approver change, you can modify the record
for that approver by performing the following procedure.
1. Open the list of alternates as shown previously in Viewing the Record for an
Alternate Approver.
2. Click on the name of the alternate you want to modify.
The Modify Alternate screen appears.
Figure 5-15 Modifying an Alternate Record
Managing Alternate Approver Definitions 5-11

3. Modify the fields you want to change.

6 Using a Sample Application Chapter
This chapter demonstrates how to use Get Agreement, one of the sample
applications bundled with the Approval Server.
Note The procedures in this chapter require sample users Frank Williams, Jack Miller,
Larry Goldstein, Violet Anderson, and Sue Smith to be licensed AR System login names. If
you find you cannot log in or write AR System records as the sample users, ask your
Approval Server process administrator to license the sample application login names.
6-1
Using a Sample Application
This sample application Get Agreement demonstrates an Ad Hoc process. Refer
to Ad Hoc - Approvers Choose Who Is Next on page 7-21 for the definition of
an Ad Hoc process type.
First we will use Get Agreement to request a new computer. Then we will log on
to the AR System Approval Server as different approvers to request and respond
to a More Information request, and to reassign the approval request. After all
approvers have approved the request, we will retrieve and examine the approved
form.
Requesting a New Computer

1. From Remedy User, log on to the appropriate AR System server as sample user
Frank Williams.
2. Choose File Open All tab.
The list of available forms appears.
3. From the list of forms, choose AP-Sample2:GetAgreement, and click New.
4. The AP-Sample2:GetAgreement form appears.
Figure 6-1 New Request Within Sample2:GetAgreement
5. Type I need a new computer in the Summary field.

6. Type a longer description in the Details field. Exact wording of the Details field is
not critical for this example.
7. Type the names of three sample users in the Initial Approvers field.
6-2 Chapter 6 Using a Sample Application

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.
8. Click Save to save your request for a new computer.
Approving a Request
This procedure demonstrates how an approver responds to a request. It requires
that you have completed the previous procedure, Requesting a New Computer.
1. Use Remedy User to log on as sample user Jack Miller.
The list of forms appears.
3. From the list of forms, choose Approval Central, and click Search
4. The Approval Central form appears.
Figure 6-2 Approval Central Form
5. Select AP-Sample2:GetAgreement from the Application field menu list.

The list of approvals appears.
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.
7. Select the request I need a new computer from the Matching list.
The Detail Signature form appears for that request.
8. In the Approval Status field, select Approved from the menu list.
Using a Sample Application 6-3

9. Click Save to make your change permanent.
10. Return to the Approval Central form and click View Approvals again.
Notice that Franks request no longer appears to Jack after he has approved it.

The More Information request allows approvers to ask questions and have them
answered before responding to an approval request.
This procedure requires that you followed the previous procedures regarding
Frank Williams computer request.
1. Use Remedy User to log on as sample user Larry Goldstein.
2. Use the Approval Central form to open the I need a new computer request as
shown in Approving a Request on page 6-3.
3. Click the Manage More Information button on the form AP-Sample2:DetailSignat.
The More Information dialog box appears.
Figure 6-3 More Information Dialog Box
4. Click Create a New.

The More Information form appears.
Figure 6-4 Larry Creates a New More Information Request
5. Type a question in the Question field. The exact words are not critical for this
example.
6. Type the name Violet Anderson in the To field.
A More Information request can be assigned to any valid AR System login name,
including the requester. For the purposes of this example, were asking for more
information from another approver.
7. Click Save to create the More Information request.
8. Click Cancel on the More Information dialog box to close that window.
9. Return to the Approval Central Form and click the View My Approvals button.
10. Notice the Approval Status field has changed from Pending to More Information.
Figure 6-5 More Information Status
For Larry Goldstein, the status of this request becomes More Information until
Larry changes it. However, for other approvers the status field 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 whether the More
Information request was seen by Violet.

Responding to a More Information Request
These steps show you how to answer a More Information request.
This procedure requires that you followed the previous procedures creating Frank
Williams computer request, and Larry Goldsteins More Information request.
1. Use Remedy User to log on as sample user Violet Anderson.
2. Use the Approval Central form to open the I need a new computer request as
shown in Approving a Request on page 6-3.
3. Click the Manage More Information button.
A list of forms appears displaying Violets More information requests.
4. Open the Pending item from Larry Goldstein.
The More Information form appears with the Response field enabled.
Figure 6-6 Responding to a More Information Request
5. Type a response to the More Information request in the Response field. The exact
wording is not critical to this example.
If Violet wants to review Franks original request, she could click the button Open
Related to display it.
6. Click Save to make your changes permanent.
7. Refresh the list of matching forms.
The More Information Request is no longer visible to Violet after she responds to
it.

Note The ability to reassign a request may not be available in all processes.

These steps show how an approver can transfer a request to another approver
without otherwise responding to the request.
This procedure requires that you followed the previous procedures to generate
Frank Williams computer request. You must be logged in as Violet Anderson.
1. Return to the Approval Central form.
4. Select the request I need a new computer from the Matching list.
5. Type Sue Smith In the Reassign To field.
Figure 6-7 Reassigning an Approval Request to Sue Smith
6. Click Save to make your changes permanent.

Franks request is no longer available for Violet to approve or reject. Only Sue
Smith and Larry can see Franks request now.
Displaying Answers to More Information Requests

These steps show you how to display and review More Information responses. To
respond, you must use the procedure, Responding to a More Information
Frank Williams computer request through Violets More Information responses.
1. Use Remedy User to log on as sample user Larry Goldstein.
1. Open the Approval Central form.
Note The Manage My More Information button on Approval Central displays questions for
you. Questions for others to answer are displayed with the Manage More Information
button on the Detail Signature form for the associated request.
4. Double-click the request I need a new computer from the Matching list.

The Detail Signature form appears.
Figure 6-8 Click Manage More Information button
5. Click the Manage More Information button.

The More Information dialog box appears.
Figure 6-9 Larrys Completed More Information Request
Note The Manage More Information button displays all associated More Information
requests, regardless who created or answered them. Clicking the Manage My More
Information button on Approval Central displays questions for you to answer.
6. Select the completed More Information request and click Open.

The More Information form appears. With Violets response, Larry now has
sufficient information to approve Franks request.
7. Click cancel to close the More Information form.
8. Click cancel to close the More Information dialog box.
9. Return to the Detail Signature form.
10. In the Approval Status field, select Approved from the menu list.
11. Click Save to make your change permanent.
Jack and Larry have approved, Violet has reassigned the request, so now only Sue
Smith remains to approve or reject Franks computer request.
Finishing the Sample Request

These steps show you how to verify the status of a request after approval.

Frank Williams computer request.
1. Log in as Sue Smith and approve the request as shown in Approving a Request
on page 6-3.
2. Log out as Sue Smith.
3. Log in as Frank Williams.
The list of available forms appears.
5. From the list of forms, choose AP-Sample2:GetAgreement, and click Search.
An empty Get Agreement request appears.
6. Click Search
The list appears displaying Franks Get Agreement requests.
7. Double-click the request for the new computer.
8. Notice the status of the request is now Approved.
Figure 6-10 Status Field Displays Approved
Franks Request has been approved.
Summary of Sample
The procedures in this chapter demonstrated how to respond to an approval
request, as well as how to create and respond to a More Information request. You
also learned how to reassign a request to another person when that option is
available.
Summary of Sample 6-9

7 The Process Administrators
Guide Chapter
This chapter introduces concepts to prepare Process Administrators for setting up

and maintaining the Approval Server.
This chapter covers the following concepts:
The Process Administrator
Key Features of the Approval Server
Common Rules and Operations
Approval Process Types
Notifications
7-1
The Process Administrator
A Process Administrator is an AR System user with the authority to define an
approval process for others to use. The first Process Administrator must be set up
by the AR System administrator, but others can be set up by an existing Process
Administrator.
The Process Administrator is a more powerful authority than the signature
authorities (approvers) who actually sign off for approval requests. As a Process
Administrator, you perform three major tasks, and determine who can share each
responsibility with you.
Process Administrator Responsibilities

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

A Process Administrator has the authority to construct, configure, and manage all
approval workflow, across every process within the AR System. Process
Administrators also have the ability to create and delete other Process
Administrators.
Delegating Process Administration Capability

A Process Administrator can also delegate limited authority to individuals who
need authority for specific approval processes. Limited Process Administrators
manage only the parts of approval process that have been specifically delegated
by a regular Process Administrator.
7-2 Chapter 7 The Process Administrators Guide

Override Only Process Administrators can approve or reject requests when
they are not on the Approver List. However, an override only administrator
cannot create or modify process definitions.
Specific Process means a user can act as a full Process Administrator, but only
for a specific process.
For example, you may wish to create a limited-authority Process Administrator
for only purchasing approvals, or allow a department manager to override
approval processes within only that department.
Refer to Setting Up Administrator Capabilities on page 8-6 for the discussion of
setting up Process Administrator rights.
Key Features of the Approval Server

The two main components of any approval request are the data collected by a
request, and the process used to generate approvals
Approval Data
The most important data generated by an approval request consists of the
signatures of every person who approves or rejects the request. Other data useful
for an audit trail includes More Information requests and specific dates and
times for each activity. The Approval Server collects this information on 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.
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.
Key Features of the Approval Server 7-3

Join forms display information about your application and the approval forms.
Refer to the Connecting an Application to the Approval Server on page 12-2
for more information on 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
what order people sign the card, but it would be inappropriate to request a
second signature from someone who has already signed. Additionally, no one is
usually required to sign a birthday card. And finally, it is inappropriate to request a
signature from the person with the birthday!
Processes abide by rules such as these without anyone thinking of them as rules.
However, the Process Administrator setting up a business process must
determine and implement all the rules.
Processes and Rules

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

The next section examines the common rules followed by all approval processes,
followed by a section that applies the rules to the four different process types.
Common Rules and Operations

The Approval Server automatically includes certain rules and operations in every
approval process:
Self Check Rules - Preventing Unnecessary RoutingCan I approve my own
request?
Next Approver Rules - Determining Who Is NextWho is the next approver?
Approver Response - The Signature LineHow did this approver react?
Routing Completion Check - Whos Left?Does this persons approval
complete the request?
Process Done RulesIs the request approved or rejected?
The following diagram displays the process of any approval request:
Figure 7-1 The Approval Process
An approval process starts when someone requests an approval.

1. The Approval Server immediately performs a one-time Self Check to determine
whether the requester has sufficient authority to approve his or her own request.
Common Rules and Operations 7-5

If so, the approval process is done and the approved workflow is returned to the
requester.
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.
3. If an approver rejects the request, the approval process is done and the rejected
workflow is returned to the requester.
4. If a person approves the request, then the Approval Server checks whether
enough people with sufficient authority have signed to Complete the
authorization.
5. When the approval process is Done, the Approval Server determines if the
approval was successful, and takes appropriate action.
Note The difference between complete and done is important. When a request is
complete, this means that it has been routed to all approvers. Even when routing is
complete, all required approvers have not necessarily responded. The request is not done
until all approvers have approved or rejected the request.
Process Complete Versus Process Done
Sue has a purchase order which 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.
The Approval Server uses rules to determine the exact sequence of events to
process an approval request. As Process Administrator, you should have some
background on the types of rules available before you attempt to create your own
approval processes.

Self Check Rules - Preventing Unnecessary Routing
Self Check rules determine whether the requester has sufficient authority to
approve his or her own request. The Self Check includes two tests that are
conducted by rules of different types, auto approval and self approval, as shown
in the following diagram.
Figure 7-2 Details of Self Check Rules
Auto Approval Check

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

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

Get Authority Rules Get Authority rules collect data, such as a dollar
amount, or other information that determines the boundaries of this approvers
authority. These rules do not use this information yet. Get Authority just lets you
set up a process to collect information used for later decision making.
There are two types of authority rules: Get Authority and Get Authority Self.
They perform identical operations and may be treated the same. The difference
between these two types is that Get Authority Self rules are performed only in the
Self Approval Check portion of the approval process, allowing data gathering
unique to Self Approval rules. Alternately, the Get Authority rule is performed
both at the self check as well as later in the process during Completion rule
processing, allowing a common data gathering mechanism.
Note There is a third type of Get Authority rule, called Get Authority Regular, that is
performed only during Completion processing. Refer to Get Authority Regular Rules on
page 7-14 for a discussion of Get Authority Regular rules.
The information collected by your Get Authority rules is used by Self Approval
rules in the next operation of the Self Check.
Self Approval Rules The Self Approval check is completed when it executes
Self Approval rules. Data collected earlier under the Get Authority rules are
tested under Self Approval rules. The result of this test determines whether the
requester has sufficient authority to complete the request.
When Self Approval occurs, the request is done, and routed back to the requester.
Example of Self Approval
If Frank requests approval for a $50 business lunch, a $40 auto approval rule does not
occur. After failing the auto approval test, the Self Check continues with a Get Authority or
Get Authority Self rule to collect Franks employee status, as a permanent employee who
has authority to approve lunches up to $100. The Self Approval rule then tests whether
Frank-the-permanent-employee has authority to approve his own $50 lunch.
To summarize, the Self Check tests a request using Auto Approval and Self
Approval rules. If the rules test successfully, the request is done, and the
approved workflow is returned to the requester.

Approver Roles
If the Self Check cant approve a request, then the request is routed to an approver
with more authority than the requester. Authority for this approver can be
established by a relationship with the requester, or by a role within your
company.
Consider the authority behind individuals in your organization. Generally
authority is based on the persons relationship with the requester, or based on the
role that this approver has within the organization. A relationship could be direct
supervisor. A role could be marketing managers or company director. Think of a role
as membership in a group, or a characteristic shared among many individuals.
Role Versus Relationship
Imagine your company allows any manager to approve a business lunch for up to $100. As
Process Administrator, you would set up a manager role within the Approval Server and
attach the names of all your managers to that role. Then when Frank requests approval for
a $75 lunch, the request can be approved by any individual assigned to the manager role.
Franks actual manager Jack can approve the request, or any of Jacks peers can do so, as
long as they have the role of manager assigned within the Approval Server.
Alternately, if your company requires a lunch request above $100 to be approved by only
the individual who supervises the requester, you can set up the process so only Jack,
Franks direct supervisor, is allowed to approve Franks $150 request. In this case, the
individual Jack has a specific relationship with Frank, and this relationship is set up within
the Approval Server.
The relationships and roles held by individuals determine the valid Approver List
for any given process. With a valid Approver List, you can set up rules to find
them. These rules, called Get Next Approver rules, are discussed in the next
section.
Next Approver Rules - Determining Who Is Next

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

Get Next Approver - Automatically
Prepare (Prep) Get Next Approver rules These rules gather information to
be used by the Get Next Approver rules. These rules are similar to the rules for
Get Authority Rules on page 7-8, in that they gather information for later use.
The approval process is not advanced by the Prepare Get Next Approver rules. It
is advanced by the following Get Next Approver rules that use the information.
Note If you are familiar with AR System workflow, consider that a set field action occurs
with Prep Get Next Approver rules. Values are placed in certain fields, but nothing acts
upon these values yet.
Get Next Approver rules These rules route requests to the next valid
approver. When the Process Administrator sets up an approval process, he or she
determines a list of valid approvers. Get Next Approver rules determine who is
next in the Approver List and creates signature lines for the people found.
Get Next Approver - Manually

Ad Hoc Approvers In most cases the Process Administrator sets up a process
to route a request automatically to the proper approvers. However, the Process
Administrator can allow a person holding the request to circumvent the normal
routing with a manual selection of next approver. Manual selection is
accomplished with Ad Hoc Override capability.
When enabled and selected, the Approval Server checks Ad Hoc approvers
against the list of valid approvers for the current process. Once validated, an Ad
Hoc approver continues with the approval process exactly as if the approver had
been assigned by normal rules.
Note An Ad Hoc process type, discussed in Approval Process Types on page 7-17,
should not be confused with the Ad Hoc override described here. Ad Hoc overrides allow
specific approvers an option to alter a predetermined routing. In an Ad Hoc process, there
is no predetermined routing, and the current approver must always select the next
approver.
Validate approver The Approval Server allows protection from inappropriate

Ad Hoc assignments with validate approver rules. These rules allow testing of Ad
Hoc approvers to ensure 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.
Figure 7-3 Get Next Approver Rules
To summarize, Next Approver Rules determine the next approver or set of

approvers for the request and creates appropriate signature lines for them. The
request is then prepared for the next approver(s) 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.
Next Approver Rules - Determining Who Is Next 7-11

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

If an approver asks for more information, the approver sends a more information
request to another user. The Approval Server identifies the approval request with
a More Information status, but no other action occurs within the approval
processing.
Figure 7-4 Approvers Have an Option to Pause and Ask for More Information
The Approval Server allows an approver to hold, approve, or reject a request

without waiting for the more information response. When this occurs, the More
Information request is terminated.
Reject
If the approver rejects a request, the request moves to the Process Done stage, as
described in Process Done Rules on page 7-15. No more routing occurs, and it is
withdrawn from approvers who have it on hold or requested More Information.
Approve
When an approver approves a request, the Approval Server processes the request
against the Routing Completion Check, discussed in the next section.

Routing Completion Check - Whos Left?
The Completion Check determines whether conditions exist to stop routing a
request to approvers who have not yet seen it. If a Completion check is successful,
then routing stops, and no additional approvers will see the request. The request
may not be ready for Process Done rules, but a completed request has been routed
to everyone who must respond.
Completion Rules Overview
When Jack approves a business expense for $100, a Completion Check determines whether
Jack has sufficient authority for that amount, for $100. If Jack can authorize that amount,
the process passes the Completion Check. If Jack does not have such authority, then the
Completion Check fails, and the routing of this request continues to another approver.
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.
However, some processes are designed to run out of approvers. A process which
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.
Routing Completion Check - Whos Left? 7-13

Routing Completion check rules are shown in this diagram.
Figure 7-5 Details of Completion Check Rules
Get Authority
The Completion Check has Get Authority rules to collect information as
discussed in Self Check Rules - Preventing Unnecessary Routing on page 7-7.
Get Authority Regular Rules

The Completion Check introduces Get Authority Regular rules. Get Authority
Regular rules collect data only during the Completion check. Get Authority
Regular rules test whether sufficient authorization exists to stop routing an
approval request. A process is complete when the Approval Server has routed the
request to all required approvers even if they have not yet all responded.
Routing Completion rules test whether a specific condition has been fulfilled.
When the condition has been fulfilled, the Approval Server stops routing the
request to new people.
No Completion If Completion rules are not fulfilled, the Get Next Approver
rules are performed, and the request is routed to the next approver.
If no new approvers are found by the Get Next Approver rules, the Approval
Server checks the Approval Success field of the Process Definition form. If this
field is set to No More Approvers, then the process is done with a status of

approved. If the Approval Success field is set to Completion Rule, then the
process is done with an error state, because there are no more approvers and
no Completion rule has succeeded.
Successful Completion If Completion rules are fulfilled, the request is routed
to no additional approvers. If there are outstanding signatures active when
Completion rules are fulfilled, the request remains active until either all
approvers approve or one rejects the request.
Example of Routing Completion Check
Previously, authorizing a business lunch required a person with authority to approve a

dollar amount. When Franks $150 lunch request arrives at Jacks desk, if Jack has author-
ity for $150 then the process is complete. If Jack has authority for a lesser dollar amount,
then the approval process does not pass the Completion Check until someone approves
with authority for at least $150. This Get Authority rule tests completion against a specific
condition of a dollar amount.
Imagine a different process that ignores dollar amounts, and instead requires the sign off
from two steps up the chain of command, so Frank needs both his manager Jack, plus
Jacks manager Larry to approve Franks business lunch request. When Frank gets his two
signatures, no more approvers are required, so the process is complete.
Process Done Rules

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

Summary of Common Process Elements
This completes the discussion of common elements of any approval process:
Self Check
Get Next Approver
Approver Response
Completion Check
Process Done
You also learned about individuals versus roles and Ad Hoc routing. The
following diagram displays all elements together.
Figure 7-6
The next section shows how the Approval Server assembles these concepts into
four process types, useful for various business practices.

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

Do your approval requests travel a straight line, where each approver has a
defined relationship to the next? This process is best implemented as Parent
Child.
An example of a Parent Child process is a traditional management sign-off
hierarchy, in which managers must approve workflow of the workers who report
to them. Each manager (parent) has a direct fixed relationship to the worker
(child) making a request. When multiple signatures are required, the managers
become the child as they pass the approval to their managers.
A Parent Child process requires an approver to have a fixed relationship with the
previous approver, and the next, if present. While not required, a manager-
employee relationship is often the hierarchy represented with a Parent Child
approval process.
Approval Process Types 7-17

A Parent Child Process
Figure 7-7 Parallel Parent Child Hierarchies
Imagine that both marketing and engineering need to approve each product change. Using
Parent Child processes, there would be two parallel approval hierarchies, in which market-
ing approvers send the request to their marketing managers, and the engineering approv-
ers send the request up the engineering chain of command.
The important factor to notice is the hierarchical relationship between approvers. The Par-
ent Child process ensures 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.
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 10-12 provides more
information on this type of rule and includes specific procedures.
When an approver marks an approval request as approved, the Approval
Server routes the request to the parent of that approver. There is no waiting
for all approvals to be completed before forwarding the requisition to the next
approver (based on the Get Next Approver rule).
In generating the first Approver List for a Parent Child process, the Approval
Server assumes that the previous approver is the originator of the approval
request. This means that the parent of the approval request originator
becomes the first approver.
Level Process - Routing Without Approver Relationships

Do your requests pass through individuals, committees, or departments that have
no fixed relationship between themselves? The level type process works best for
this kind of situation.
Level Process Examples
Imagine Frank wants to announce a new product at a New England trade show, and to do
this he needs approval from any project manager and at least one division manger.
Although Frank is in the West Coast Division, a Level process would permit any one
project manager to approve, Wester, Central or Eastern. Likewise a Level process would
pass the request to all three division managers for one to sign off. The order in which the
approvers see the request is defined by level, and there is no requirement that Frank has a
relationship with any approver.
Figure 7-8 Level process With Two Levels

In the second illustration, imagine that a request for a soft drink machine in a company
courtyard must be approved by the refreshment committee, the landscape committee, and
finally the maintenance committee.
Figure 7-9 Level Process With Three Levels
None of the committees reports to another, nor si there any fixed relationship, 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.
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 10-12 provides
additional information and specific procedures for defining this type of rule.

The Process Administrator needs to set up rules to determine whether a request
should appear to more than one person on a given level. For example, should
the process ask all committee members to approve a request, or should the
process route requests only to the executive council, or only to the chairperson
alone?
Ad Hoc - Approvers Choose Who Is Next

Are your approval demands so unpredictable that only the current approver can
determine the correct routing path? In this case, use the Ad Hoc process instead of
Ad Hoc override capability.
Figure 7-10 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.
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 AR System
administrator constructs menu lists containing the appropriate Ad Hoc approvers.
Custom Rule-based - Your Own Routing

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

Summary of Process Types
The Approval Server handles approval requests with one of four processes, each
with its own rules. The processes and rules are set up by you or someone you, the
Process Administrator, designate.
Table 7-1 Summary of Process Types
Routing How Is Next Approver Ad

Relationship Approver Hoc Overrides
Between Determined? Available?
Approvers?
Parent Child Yes. Fixed Get Next Optional.

hierarchy. Used Approver rule
when routing up determines
a management relationship of
chain. next approver to
current owner.
Level No fixed Get Next Optional.

relationship Approver rule
between determines the
approvers. Used level of next
when routing approver.
between
committees or
departments.
Ad Hoc No. All routing No rule Not applicable.

determined by determining the
the current next approver.
approver.
Rule-based Custom, as Custom, as Optional.

determined by determined by
the Process the Process
Administrator. Administrator.
Summary of Process Types 7-23

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.
Remedy 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 Remedy Notification Tool, 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 D-6. 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 8-8.
Configure the delay before escalations when no activity occurs using the
procedure Entering Signature Escalations on the Process Definition Form on
page 9-6.

Configure notifications for More Information requests using the procedure
Entering More Information Escalations on the Process Definition Form on
page 9-7.
Notifications 7-25
8 Working with the Approval
Server Chapter
This chapter describes the procedures that guide Process Administrators in

setting up the Approval Server. It covers the following topics:
Using the Approval Administration Interface
Setting Up Administrator Capabilities
Using Approval Notifications
Configuring Business Times
Where to Go Next
8-1
Using the Approval Administration Interface
The AP:Administration form is the main form for managing and configuring the
Approval Server. With this form Process Administrators create or configure
processes, rules, notifications, roles, forms, Process Administrators, or alternates.
You can also configure the server settings and rename forms and processes from
the Approval menu when the AP:Administration form is displayed.
Note To access the AP:Administration form, you must be an Approval Server Process
Administrator, or an AR System administrator. Refer to Setting Up Administrator
Capabilities on page 8-6 for information about creating the first Process Administrator.
The Administration Control Panel

The following procedure demonstrates using the AP:Administration form.
Accessing Approval Server Components

1. From Remedy User, log on to the appropriate AR System server.
2. Choose File Open.
The Open dialog box appears.
3. From the list of forms, select AP:Administration, and click OK.
The AP:Administration form appears.
Figure 8-1 AP:Administration Form
8-2 Chapter 8 Working with the Approval Server

The active tab determines the kind of information you manipulate when you click
the buttons along the top of the form. Each tab controls a different Approval
Server component.
To create a new Approval Server component, click the appropriate tab and click
Create. A blank version of the selected form appears.
To view or modify existing components, select a category tab. A list of the
selected components appears. Double-click one of the items on the list to
display the form for that record.
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 For
Process field. This limits the list of items displayed to those associated with the selected
process.
The Administration Menu

A custom Approval menu appears while you view the AP:Administration form.
The Approval menu contains a command for renaming individual components or
entire processes, and a command for configuring your server.
Renaming a Process or Form

The Approval Server provides you with the ability to easily rename an existing
process or form and all references to it within the Approval Server. This
eliminates the need to manually track and update references when you change
the name of a process or form.
Use the steps in the following procedure to rename a process or form.
1. Log on to the appropriate AR System server and open the AP:Administrator
form.
2. Choose Approval menu Rename.
The custom Approval menu appears when a Process Administrator views the
AP:Administration form.
The Administration Menu 8-3

The AP:Admin-Rename form appears.
Figure 8-2 Renaming a Process and All Attached Workflow
3. Select the Process option button to change a process name, or the Form option
button to change a form name.
4. Select an item to rename from the From Old Name menu list.
5. Enter a new name for the process or form in the To New Name field.
Warning: If you renamed a process manually instead of using the Rename dialog box, the
Rename command wont change names of attached rules. You must restore the process
name manually and then rename the process to rename the attached rules.
6. Select an update action for existing detail entries:

Selecting All updates both currently active and completed detail records. This
options takes more time but will ensure that all detail records reference the new
name.
Selecting Active 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 option button to change the name of the object as
the first step of the rename action.
By default, this option is active.
Note If you have already manually changed the process or form name, you can deselect
this option 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 Perform Rename to execute the rename action.

Configuring the Server Settings
The Server Settings Basic tab lets you configure the Approval Server to generate a
log file for debugging purposes, and lets you customize other settings of the
Approval Server. Refer to Defining an Approval Notification on page 8-10 for a
description of the other tabs of the AP:Admin-ServerSettings form.
1. To configure server settings, display the AP:Administration form and choose
Approval menu Server Settings.
The AP:Admin-Server Settings form appears.
Figure 8-3 Approval Menu Server Settings
2. Select the Approval option button if you want the Approval Server to generate a
log of approval activity.
Debug mode is an optional field. The log is a text file.
3. If you activated the preceding option button, type a system path for the debug log
file.
Log File Name is an optional field. It is required if the Debug Mode option button
is activated, but otherwise ignored.
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.
A larger number increases AR System performance.
A smaller number is useful while creating and testing a process.
The Administration Menu 8-5

A zero (0) in this field causes immediate implementation of a definition.
5. Type a number in the Private Type the RPC socket number field.
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 ARWeb forms are stored in the Virtual Web
Document Directory field.
Leave this field empty if you do not have ARWeb installed for web-based
approvals.
7. Click OK to save your changes.
Setting Up Administrator Capabilities

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

1. Open the AP:Administration form. Refer to Using the Approval Administration
Interface on page 8-2 for the procedure.
2. Select the Administrator tab and click the Create button.

The AP:Process Administrator form opens.
Figure 8-4 Creating a Process Administrator
3. Enter a valid user name in the Individual field.
Note This user must be defined as a member of the group Approval Admin, ID 402, in the
User form for this AR System server before the settings you make here will take effect.
4. Select Full Admin or Override Only Admin from the Authority menu list.
Full Admingrants this user the ability to modify processes as well as the
ability to approve or reject a request regardless of the normal process.
Override Only Admingrants this user the ability to approve or reject a
request regardless of the normal process.
5. Select one of the four following options from the Notify Method menu list.
NoneNo message is sent.
NotifierUsers are notified when they run Remedy Notifier. For more
information about Remedy Notifier, see the AR System Server Administrators
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 NT). 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, Remedy Notifier is used.
6. 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.
Setting Up Administrator Capabilities 8-7

The ability to easily turn administrator capabilities on or off allows you to set up
entries for individuals who may need administrator capabilities only on a
temporary basis. For example, you can store information for an individual who
periodically covers for an administrator.
7. Select a Covering option.
Selecting All gives the individual administrative capabilities for all processes
defined in the AP:Process Definition form. If this is not what you want, select
Specific Process and then select a process from the Process Name menu list.
8. Click Save make your changes permanent.
Using Approval Notifications

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

Use the form AP:Admin-ServerSettings to determine which Approval Server
activities are capable of triggering notifications and escalations. This form enables
the notification and escalation settings for all other Approval Server forms.
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.
Enabling Events for Notifications

1. Open the AP:Administration form as shown in Accessing Approval Server
Components on page 8-2.
You must display AP:Administration to enable the custom Approval menu.
2. Choose Approval menu Server Settings.
The Server Settings form appears.

3. Click the Notifications tab.
Figure 8-5 Defining Approval Events That Trigger Notifications
4. Select the appropriate option button for each event.

Select Disabled if you never want the event to trigger a notification.
Select the Enabled option button 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.
Defining the Events to Trigger Notifications 8-9

5. Click the Escalations tab.
Figure 8-6 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 OK to save your changes.
The events determined here are now able to trigger notifications and escalations
using the AP:Notification form.
Defining an Approval Notification

The form AP:Notification allows you to define who receives notification, the
notification message, when the message is sent, and by what method. The
Approval Notification form has four tabs:
Notification DescriptionFor basic descriptive information about the
notification.
QualificationFor selecting the event trigger and defining any additional
conditional statement for triggering the notification.
Notification DetailsFor notification parameters, such as the method of
delivery, who receives the notification, and the text message.
Administrative InformationFor displaying assignment, help text, and
change history.

Fields with bold headings are the required fields, others are optional.
Defining an Approval Notification

1. Open the AP:Administration form. Click the Notification tab and click the Create
button. The AP:Notification form is displayed.
Figure 8-7 Define the Name of the Notification
2. Enter a name in the Notification Name field.

Use a name that indicates the type of notification, such as New-Signature
Notification.
3. Select the appropriate process from the Process Name menu list.
Refer to Creating a Process on page 9-2 if you have not set up any processes to
select.
4. Click the appropriate notification Status.
The Status option allows you to temporarily enable or disable this notification
without having to delete or re-enter notification entries. Refer to Enabling Events
for Notifications on page 8-8 to enable and disable which events trigger
notifications for the entire process.
Defining an Approval Notification 8-11

5. Click the Qualification tab.
Figure 8-8 Determine the Event That Triggers the Notification
6. Select one of the following Notify On options from the menu list. This option
specifies the approval cycle event that triggers the notification.
Table 8-1 Notification Descriptions
Notify On Event Event That Triggers Default Notify List
New Signature When a new signature line is Approver list.

added to the approval request.
Approve When the approval request is Approver list minus

approved. current approver.
Reject When the approval request is Approver list minus

rejected. current approver.
Alternate When an alternate approves Individual Approved

Approve the approval request. for.
Alternate Reject When an alternate rejects the Individual Approved

approval request. for.
Override Approve When a user with override Approver list.

capability approves the
approval request.
Override Reject When a user with override Approver list.

capability rejects the approval
request.

Global Approve When an administrator Approver list.

performs a global approve,
terminating a process for a
request.
Global Reject When an administrator Approver list.

performs a global reject,
terminating a process for a
request.
Reassign When an approval is Approver list.

reassigned to a different
approver.
Error When there is an error in the Individual who

approval signature. approved or rejected.
Cancel When an approval request is Approver list.

cancelled.
More Info Return When a request for more Individual who

information is fulfilled. requested more
information.
Reject by Later When the approval request is Approver list.

Level rejected after this signature
has approved.
Cancel at Later When the approval request is Approver list.

Level cancelled after this signature
has approved.
Rejected by When the approval request is Approver list.

Another Approver rejected by another signature
record.
Hold When an approval request is Approver list minus

put on hold. current approver.
More Info When more information is Approver list minus

requested by an approver. current approver.
Does not include
requester.

Still Active When an approval request is Approver list.

in an approval pending state
and there has been no action.
Still Active When a Still Active Approver list.

Repeat notification has been sent and
there is still no action.
Still Pending When an approval request is Approver list.

on hold in the approval cycle
and there has been no action.
Still Pending When a Still Pending Approver list.

Repeat notification has been sent and
Still Hold When a Hold notification has Approver list.

been sent, but there is still no
action.
Still More Info When more information has Approver list.

been requested for a approval
request and there has been no
action.
Still More Info When a Still More Info Approver list.

Repeat notification has been sent, but
Still Error When an error in the approval Approver list.

cycle has occurred, but there
has been no action to correct
the error.
Still Error Repeat When a Still Error notification Approver list.

has been sent, but there is still
no action.
Change After When a change occurs that all Approver list.

Approve past approvers should know
about.

7. If applicable, define an additional Qualification statement that will trigger the
notification. This allows you to define a trigger that is in addition to the Notify On
condition.
8. Click the Details tab.
Figure 8-9 Determine the Method and Content of the Notification
9. Select one of the following notification options for the Method field:
Notification Description
None Send no notification.
Notifier Users are notified when they run Remedy Notifier. For
more information about Remedy Notifier, see the
Remedy User online help.
Email Users are notified by email. If the contents of the Send To
field do not match an existing user or group definition,
the system interprets the field contents as a literal
address and sends the notification to that address by
SMTP mail (UNIX) or MS-Exchange (Windows NT).
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 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, Remedy Notifier
is used.

10. Select an option for the Send To field, which will indicate where the notification is
to be sent. Notifications are sent to users or roles, or the Approval Server can write
to a form field.
Send To Target
Notify List Send to the default notify list for the selected Notify On
option.
Other Specify an individual, a role, a list of individuals, or
roles, or a field reference to a field containing
individuals or roles.
11. If email or User Default is the message delivery method, enter a subject line for
the notification message.
You can use the field list button to include field values in the subject line.
12. To attach additional field information to the notification, enter or select the field
names in the Additional Fields text box.
13. Enter a text message in the Message field.
You can use the field list button to include field values in the Message field.
14. Click Apply to save your changes.
Configuring Business Times

The Approval Server uses the data in the business time forms for scheduling
approval notifications. The following procedures demonstrate using these forms.
Configuring Business Time Workdays

1. Log on to the appropriate AR server.
2. Choose File Create a New.
3. Select Business Time Workdays and click OK.

The Business Time Workdays form appears.
Figure 8-10 Business Time Workdays Form
4. In the Tag field, use the menu list to select an existing workday schedule or type
in a new name.
5. Modify the Open Time and Close Time fields, as appropriate for your company.
Configuring Business Time Holidays

1. Log on to the appropriate AR server.
2. Choose File Create a New.
3. Select Business Time Holidays and click OK.
The Business Time Holidays form appears.
Figure 8-11 Business Time Holidays Form
4. In the Tag field use the menu list to select an existing holiday schedule or type in a
new name.
Configuring Business Times 8-17

5. 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 may interpret the dates incorrectly.
Where to Go Next
Setting up Processes, Rules, and Roles are covered in separate chapters:
Chapter 9, Defining an Approval Process
Chapter 10, Defining Approval Rules
Chapter 11, Managing Users and Roles

9 Defining an Approval Process Chapter
This chapter describes the procedures for using Remedy User to create and
modify approval processes.
This chapter covers the following topics:
Using the Process Definition Form
Creating a Process
Working with Existing Processes
9-1
Using the Process Definition Form
Use the AP:Process Definition form to create and modify approval processes.
This form contains multiple sections for defining the process:
Process DefinitionFor basic information about the process, such as process
name, application, type, and approval success criteria.
Signature EscalationsFor scheduling notifications when approval requests
are awaiting action. This section includes the following subsections: Normal
Priority Notification, Urgent Priority Notification, and Low Priority
Notification.
More Information EscalationsFor scheduling notifications when an
approval request is in the More Information state.
Administrative InformationFor displaying assignment, help text, and
change history.
Creating a Process
This section describes how to create a process using the Process Definition form.
In most cases, you need only one process for your approval request, but it is
possible to create multiple processes.
Use the following procedures to create an approval process. Each of the tabs on
the AP:Process Definition form is described in a separate procedure. You may not
need to follow all of the procedures, depending on how you decide to define your
approval process.
Entering Process Information on the Process Definition Form

1. Open the AP:Administration form.
See Using the Approval Administration Interface on page 8-2 for the procedure.
2. Click the Process tab and click the Create button.
9-2 Chapter 9 Defining an Approval Process

The AP:Process Definition form appears.
Figure 9-1 AP:Process Definition Form, Process Definition Tab
3. In the Process field, enter a name for the new process.

Process names must be unique and no more than 30 characters (including spaces).
It is helpful to make the name descriptive and indicative of the process function.
4. From the Application field menu list, select the AR System application workflow
that you are connecting to the Approval Server.
Note Applications must be entered in the Form tab of AP:Form to be available in the
Application pull-down list.
5. From the Type menu list, select a process type.

For a description of the different types of processes, see Approval Process Types
on page 7-17.
6. Select a process status from the Status menu list.
You may 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.
Creating a Process 9-3

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 Use this value to indicate that the Approval Server should
Approvers consider the approval process finished when all signature lines
are complete. (A completion rule can also be used to end the
process.)
Completion Use this value to indicate that the Approval Server should
Rule expect a Completion rule to determine the successful
completion of the approval process. If you select this option,
you must create a Completion rule and associate it with this
process or the process will never complete.
8. Select a value for the If Multiple Approvers menu list.

This field applies only if you are defining an Ad Hoc process or are going to allow
Ad Hoc overrides (refer to step 5 of this procedure for process type selection). The
value you select determines how many signature line records the Approval Server
creates when building an approver list.
The options are:
One Must Sign Use this value to create a single signature-line record for a list
of potential approvers. The signature-line is complete when
one of the approvers acts on the requisition.
The field for approver names on a signature-line record is
limited to 255 characters. If you select this option, the list of
approver names must fit within this limit. Using roles may help
you to work around this limitation, if applicable.
This option overrides the If Multiple Approver setting on any
roles selected as an approver.
All Must Sign Use this value to create a separate signature line for each
approver on the approver list.
If an approver list includes roles, the If Multiple Approver
setting for the specific role determines whether the role is
expanded into individual signature-line records for each
member of the role or a single signature-line record is created
for the entire role. See Defining Roles on page 11-2 for more
information on the If Multiple Approver setting for roles.
Allow Only One Use this value to create a single signature line for one
Approver individual.
If you specify multiple names the Approval Server returns an
error.

9. If you are using a parent child, level, or rule-based type process, specify whether
to allow Ad Hoc additions to an approver list by selecting an option from the
Allow Ad Hoc Next Approver list.
The options are.
Anyone Allows anyone to specify the next approver. This includes the
requester and approver.
Approver Allows only the approver and not the submitter to specify the
next approver.
No one 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.
10. From the Request Owner Field menu list, select the field identifying the owner of
the approval request.
11. From the First Approver field menu list, select the field identifying the first
approver.
If the process is an Ad Hoc process or if you specified Anyone for the Allow Ad
Hoc Next Approver, then you must specify a field to contain an initial approver
value.
12. From the Require Password list, indicate whether approvers must enter their
password when acting upon an approval request.
Use the Validate Approvers menu list to specify whether 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.
13. 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 To use a Get Next Approver rule to determine the first
Approver Rules approver.
Assign To Owner If To use the requester as the first approver if the requester
Approver is 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 To use the requester as the first approver in all cases.
Owner

Entering Signature Escalations on the Process Definition Form
Use this tab 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) in the Signature Escalations section of the AP:Process Definition form.
1. Open the AP:Process Definition form if it is not already open.
Refer to Entering Process Information on the Process Definition Form on
page 9-2 for the procedure to open this form.
2. Click the Signature Escalation tab.
3. On the Signature Escalation page, click the tab for the notification priority level on
the AP:Process Definition form: Normal, Urgent, or Low.
Figure 9-2 Configure What Happens When a Request is Not Acted On
Note If you do not enter parameters for either urgent or low priority notifications, the
parameters you enter for normal priority are used. You can use the urgent or low priority
sections to enter only parameters that are different than those you set for normal priority.
4. Enter the names of the Workday Schedule and the Holiday Schedule 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. Refer to Configuring Business
Times on page 8-16 for information about setting up business times.

5. To change the state of an approval request automatically if no signature action
occurs after a specified interval, enter the Automatic Action parameters:
a. Enter a number in the After Interval field to indicate when you want the state
changed, and select what this number represents from the Unit list.
For example, if you want the state to change two days after the approval
request enters a certain state, enter 2 in the After Interval field, and select
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.
6. 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.
7. If you want to send notifications when the approval request remains in a certain
state 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.
Entering More Information Escalations on the Process Definition

Form
Use this tab to configure settings that control notifications when a More
Information request has been waiting too long without response. For example,
you can set up a notification to be sent when a More Information request has been
outstanding for two days.
1. Open the AP:Process Definition form if it is not already open.
Refer to Entering Process Information on the Process Definition Form on
page 9-2 for the procedure to open this form.

2. Click the More Information Escalations tab of the AP:Process Definition form.
Figure 9-3 More Information Escalations
3. Enter the names of the Workday Schedule and the Holiday Schedule 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. Refer to Configuring Business
Times on page 8-16 for information about setting up business times.
4. If you want to send notifications when a signature line has been outstanding (in
any state) for too long, specify the Notifications: Still Outstanding parameters:
a. Enter a number in the First Interval field to indicate when you want the first
notification sent, and select what this number represents for the Unit list.
For example, if you want the first notification sent two days after the approval
request enters the More Information state, enter a 2 in the First Interval field
and select Day from the Unit list.
b. If you want a second notification, enter a number in the Repeat Interval field
and select what this number represents from the Unit list.
5. Click Save to save your process.

Working with Existing Processes
The following sections describe how to modify, delete or rename an existing
process. Refer to Creating a Process on page 9-2 for information on specific field
requirements.
Modifying Processes
Follow these steps to modify an existing process.
Modifying a Process
2. Select the Process Definition tab.
3. Double-click the process you want to modify or select the process and click the
Open button.
The Process Definition form appears (Figure 9-4).
Figure 9-4 Modify Individual - Process Definition
4. Modify the appropriate process fields using field requirements described in

Creating a Process on page 9-2.
5. Click Save to save your process.
Working with Existing Processes 9-9

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.
Deleting Processes
2. Select the Process tab.
3. Select the process you want to delete.
4. Click Delete.
Figure 9-5 Confirm Process Deletion
5. Verify the name of the process and click Yes to delete this approval process.
The process is deleted and longer appears in the list of processes.

Renaming Processes
Renaming a Process
2. Select the Process tab.
3. Select the process you want to rename.
4. Select Admin menu Rename.
Figure 9-6 Renaming a Process
Note The Admin menu appears only when the AP:Administration form is open.
5. Select the appropriate Rename option button.
Form renames only the form.
Process renames the process, forms, and cross references.
6. Select the old proces name from the menu list in the From Old Name field.
7. Enter a new process name or select one from the menu list in the To New Name
field.
8. Select the appropriate Update option button.
All renames both closed and current AP:Detail records.
Only Active Objects renames only current AP:Detail records.
This option button setting determines whether the closed AP:Detail records are
renamed. All structured definitions and current AP:Detail are renamed for either
setting.
Renaming Processes 9-11

9. Select the Including Object Itself option button if you want to rename the process.
Usually you should select Including Object Itself. However, if you have
previously renamed the process or form using the name from step 7 you can leave
this option button unselected.
10. Click Perform Rename to complete the action.

10 Defining Approval Rules Chapter
This chapter describes how to use Remedy User to create and modify approval
rules.
The Rule Definition Form
Working with Auto-Approval Rules
Working with Self-Approval Rules
Working with Prep Next Approver Rules
Working with Get Next Approver Rules
Working with Validate Approver Rules
Working with Get Authority Rules
Working with Get Authority Regular Rules
Working with Get Authority Self Rules
Working with Completion Rules
Working with Approval Process Done Rules
Working with Existing Rules
10-1
The AP:Rules Definition form consists of three tabbed views (depending on the
type of rule):
BasicFor identifying information about the rule and, depending on the rule
type, a qualification statement.
Set FieldsFor specifying the action to be executed by the rule if a transaction
passes the qualification statement.
Administrative InformationFor reviewing assignment, help text, and change
history.

To create a new rule you need to open the Rule Definition form from the
AP:Administration form. Use the following procedure for opening the form.
Creating a Rule
2. Click the Rule tab and click the Create button.
The AP:Rule Definition form appears.
Figure 10-1 New Rule Definition
10-2 Chapter 10 Defining Approval Rules

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 10-5
Working with Self-Approval Rules, on page 10-7
Working with Prep Next Approver Rules, on page 10-10
Working with Get Next Approver Rules, on page 10-12
Working with Validate Approver Rules, on page 10-17
Working with Get Authority Rules, on page 10-20
Working with Get Authority Regular Rules, on page 10-23
Working with Get Authority Self Rules, on page 10-25
Working with Completion Rules, on page 10-28
Working with Approval Process Done Rules, on page 10-30
Working with Existing Rules, on page 10-32
Using the Basic Tab on the Rule Definition Form

The Basic tab on the Rule Definition form is for entering descriptive information
about the rule, such as rule name, associated process name, and rule type.
Depending on the rule type, you may use the Run If field for entering a condition
statement.
An example of the Basic tab for a Get Authority rule appears in Figure 10-2.
Figure 10-2 AP:Rule Definition Form, Basic Tab
Using the Basic Tab on the Rule Definition Form 10-3

Using the Set Fields Tab on the Rule Definition Form
The Set Fields tab applies to Get Authority, Get Authority Self, Get Authority
Regular, Prep Get Next Approver, Get Next Approver, Approval Process Done,
and Validate Approver rules.
Use rules to evaluate field values from AR System forms. The Set Fields tab
enables you to set field values on forms.
The fields on this tab enable you to define the action(s) for the specific rule. For
example, with a Get Authority rule, you can define a query to retrieve a signature
authority amount from the AP-Sample:Signature Authority form and put it on
another form.
Depending on the specific rule type, the Set Fields tab provides the following
action assignment types:
Value Allows you to assign a value to a particular field.
Query 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.
SQL 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.
Process 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.
Other Allows you to specify an Action Request filter. See the Action
Request System Workflow Administrators Guide for more
information on filters.

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

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

1. Open the Rule Definition form.
See The Rule Definition Form on page 10-2 for the procedure.
2. Enter a name for the rule (or update the existing name if necessary) in the Rule
Name field.
Working with Auto-Approval Rules 10-5

3. Select a process name from the For Process field menu list.
This is the name of the process defined for your approval request workflow. All
rules must be attached to a process to be active.
4. 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.
5. 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 may be helpful to use the
Inactive status and then later activate the rules when you have completed all the
necessary rules.
6. Enter an execution order number in the Order field.
This number determines the sequence if you have two or more Auto-Approval
rules for a specific process.
7. Enter the rule condition in the Rule field text box.
You can type the condition statement or you can build it by using the qualification
bar and list. Refer to Building Qualifications in Chapter 9 of the Action Request
System Workflow Administrators 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 Auto-Approval
Rule Example that follows for a typical auto-approval rule.
8. Enter an Audit Trail 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.
9. Click Save to save the basic information for the rule.
Note Auto-Approval rules do not use the Set Fields tab.

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

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

transaction passes any of the Self-Approval rules. Self-approval rules are optional,
so if you do not define any rules, no self-approval occurs.
Defining Self-Approval Rules

To create a Self-Approval rule, use the procedure that follows.
Defining a Self-Approval Rule

name field.
3. Select a process from the For Process field menu list.
This is the name of the process defined for your approval request workflow.
All rules must be attached to a process in order to be active.
4. Select Self-Approval from the Rule Type field menu list.
fields appropriate for the specific type of rule.
Select either Active or Inactive to indicate the status of the rule. While you are
developing a set of rules for a process, it may be helpful to use the Inactive status
and then later activate the rules when you have completed all the necessary rules.
6. 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.
7. Type the rule condition in the Rule field text box.
bar and list, as described in Building Qualifications in Chapter 10 of the Action
Request System Workflow Administrators 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 10-9 provides a look at a typical Self-Approval rule.

8. Enter an Audit Trail 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 Trail Text field blank, a default message is
written to the audit trail log.
9. Click the Save toolbar button to save the basic information for the rule.
Self-Approval Rule Example

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

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

Figure 10-6 New Prep Next Approver Rule
Name field.
Rule names must be unique. There is no enforced convention for specifying rule
names, but it is helpful to make the name descriptive and indicative of the rule
function. Names can be as many as 30 characters, including spaces.
3. Select the process name from the For Process menu list.
All rules must be attached to a process in order to be active.
4. Select Prep Next Approver in the Rule Type field.
Select either Active or Inactive to indicate the status of the rule. While you are
developing a set of rules for a process, it may be helpful to use the Inactive status
and then later activate the rules when you have completed all the necessary rules.
This number determines the sequence if you have two or more Prep Next
Approver rules.
7. 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 Building Qualifications in Chapter 10
of the Action Request System Workflow Administrators Guide. When the
qualification is met, the rule actions execute.
8. Click the Set Fields tab.
Figure 10-7 Set Fields in Prep Next Approver Rule
9. 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 10-4 for a
description of the available choices.
10. 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.
11. If appropriate, select a value from the On Server field menu list to indicate the
form resides on a different server.
Current Select to indicate the form resides on the current server.
Alternate Select to indicate the form resides on a different server. You

must indicate the server by typing its name in the Server field.
12. If appropriate, type the server name in the Server field.

13. Enter a qualification statement to test for a valid approver.
Working with Prep Next Approver Rules 10-11

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

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

In a level-type approval process, individuals and roles are tied to the process with
an additional level field. The level field identifies the organizational level of the
individual or role. For example, level 1 may be project leaders and level 2 may be

section managers. Levels are always numeric values, with 0 (zero) being the
lowest level.
Note When the Approval Server creates a first approver list, it is assuming that the
previous level was -1. Therefore, finding the first level means finding the level with the
lowest number.
The Approval Server keeps track of the current approver level of each approval
request as it goes through the approval cycle.
When defining a Get Next Approver rule for a level process, be aware of the
following considerations:
You must identify the field containing the level identifier.
If you define a qualification that includes a clause to retrieve only entries with
a level greater than the current level, you save processing time by allowing the
Approval Server to skip over individuals or roles in the previous levels. This
type of clause is not required, as previous level entries are simply ignored if
they are retrieved.
Working with an Ad Hoc Process

An Ad Hoc process does not require any rules for creating an approver list
because it is expected that users fill in the next level of approver at each case. If
you want to define a process with rules that can be overridden on an Ad Hoc
basis, choose one of the other process types and configure the process to accept
overrides for selecting the next approver.
Working with a Rule-Based Process

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

To create a Get Next Approver rule, use the following procedures.
Working with an Ad Hoc Process 10-13

Defining Basic Data for a Get Next Approver Rule
Name field.
3. Select the process name from the For Process menu list.
4. Select Get Next Approver in the Rule Type field.
As soon as you select the rule type, the Rule Definition form changes to display
the fields appropriate for the Get Next Approver rule.
7. Select a value from the If Multiple Rows field menu list.
The following choices are available:
Value from first Uses the value from the first record retrieved.
Values from all Uses all of the values retrieved.
Return error Returns an error message if more than one record is retrieved.
Clear Leaves this field blank.
8. Select a value from the If Multiple Approvers field menu list.

This field value determines what occurs when more than one approver is
returned by the Get Next Approver rule. The following choices are available:
One must sign A single signature-line record is created and only one of the
approvers listed in the record is required to act upon the
approval request to consider the record complete.
All must sign 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.
9. 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.
Ending 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.
Exclusive 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.

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 Building Qualifications in Chapter 10
of the Action Request System Workflow Administrators Guide. When the
qualification is met, the rule actions execute.
See Example of Get Next Approver Rule on page 10-16 for an example of a rule
condition.
11. Click Save to save the rule.
To complete the Get Next Approver rule, continue to the next procedure for
defining the Set Fields tab data.
Defining the Set Fields Data for a Get Next Approver Rule
2. Click the Set Fields tab on the Rules Definition form.
3. Select a value from the Set Fields Type field menu list to indicate the Set Field
action assignment.
4. Select a form name from the From Form field menu list.
Defining Basic Data for Get Next Approver Rules 10-15

5. Select a value from the On Server field menu list to indicate the form location.
Current Select to indicate the form resides on the current server.
Alternate Select to indicate the form resides on a different server. You

must indicate the server by typing its name in the Server field.
Example of Get Next Approver Rule

Figure 10-8 illustrates an example of a Get Next Approver rule for a parent child
process. On the Basic tab for this example rule, you can see that there is no Run If
statement. This means that the rule always runs; there is no condition that must
be triggered.
The example rule instructs the Approval Server to take the approver records it
finds and create a single signature-line record for the list of approvers. Only one
approver action is required to consider the approval request complete. (See the
settings for the If Multiple Rows and If Multiple Approvers fields.)
In addition, the Next Approver Rule Is field is set to Ending, meaning that no
other Get Next Approver rules will be processed after this one.
The Run If statement (1=1) in this example causes this rule to always execute.
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 $Managers Name$ from the SHR:PeopleGroup

form and pushing the value into the Next Approver field on the approval request
record.
Determines
number of
signature line
records created
Figure 10-8 Example of a Get Next Approver Rule
Working with Validate Approver Rules

The Validate Approver rule enables you to verify approver names when they are
manually entered on an approval request. This applies to either an Ad Hoc
process type or an Ad Hoc override.
This rule validates the approver name at the time of entry by searching for a
match to the entered name on a specified form, for example the
SHR:PeopleGroup form.
You can define any number of Validate Approver rules. This allows you to search
more than one form to validate an approver name.
Working with Validate Approver Rules 10-17

Defining Validate Approver Rules
To create a Validate Approver rule, use the procedures that follow.
Warning Approver names in Validate User rules are case sensitive. Ensure approver
names are entered correctly or your users will be unable to approve requests that are
assigned to them.
Defining the Basic Data for a Validate Approver Rule

1. Open the Rule Definitions form.
2. Enter a name for the rule in the Rule Name field.
3. Select the associated approval request process name from the For Process field
menu list.
4. Select Validate Approver from the Rule Type field menu list.
the fields appropriate for a Validate Approver rule.
Qualification bar
Figure 10-9 Validate Approver Basic Tab

To complete the Validate Approver rule, continue to the procedure for defining
the Set Fields Data.

Defining the Set Fields Data for a Validate Approver Rule
2. Click the Set Fields tab on the Rules Definition form.
3. Select a value in the Set Fields Type field to indicate the action assignment.
4. Select a form name in the From Form field.
5. Select a value for the On Server field to indicate the form location.
Example of a Validate Approver Rule

Figure 10-10 illustrates an example of a Validate Approver rule. On the Basic tab
in this example, you can see that there is no Run If statement. This means that the
rule always runs; there is no condition that must be triggered.
Defining Validate Approver Rules 10-19

On the Set Fields tab for this rule, a match for a name entered in the approver field
($Approver$) must be found in the Managers Name field on the
SHR:PeopleGroup form.
Figure 10-10 Validate Approver Rule
Working with Get Authority Rules

To create a Get Authority rule, use the following procedures.
Defining the Basic Data for a Get Authority Rule

Name field.
3. Select the associated approval request process from the For Process field menu
list.
4. Select Get Authority from the Rule Type field menu list.

the fields appropriate for a Get Authority rule.
Qualification bar
Figure 10-11 Get Authority Basic Tab

7. Enter the rule condition in the Run If text box, if applicable.
Example of a Get Authority Rule on page 10-22 provides an example.
To complete the Get Authority rule, continue to the procedure for defining the Set
Fields Data.
Defining the Set Fields Data for a Get Authority Rule

2. Click the Set Fields tab on the AP:Rules Definition form.
3. 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.
This value indicates where the rule should search for the requested data; for
example, the AP:Signature Authority form.
Working with Get Authority Rules 10-21

6. 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).
7. Enter the name(s) of the fields to receive the data and the name(s) of the fields
where the data is located.
You can use the field list button to the right of each of these fields to select the
appropriate field names.
Example of a Get Authority Rule

Figure 10-12 illustrates a typical Get Authority rule. In this example, the rule is
defined to retrieve data about the person currently logged in and acting upon the
requisition ($Approver$ = LoginName). The value in this persons
DollarSigningAmount field from the AP:Signature Authority form will be written
to a temporary field named TempReal 1.
The value in the temporary field is then available for use by any Self-Approval or
Completion rules.
Figure 10-12 Get Authority Rule Example

Working with Get Authority Regular Rules
To create a Get Authority Regular rule, use the procedure that follows.
Defining the Basic Data for a Get Authority Regular Rule

Name field.
3. Select the appropriate approval request process from the For Process field menu
list.
4. Select Get Authority Regular from the Rule Type field menu list.
appropriate fields for a Get Authority Regular rule.
Qualification bar
Figure 10-13 Get Authority Regular Basic Tab

6. Enter an execution order number in the Order field, if applicable.
Example of a Get Authority Regular Rule on page 10-24 provides a look at a
typical Get Authority Regular rule.
Working with Get Authority Regular Rules 10-23

To complete the Get Authority Regular rule, continue to the procedure for
defining the Set Fields Data.
Defining the Set Fields Data for a Get Authority Regular Rule
3. Select a value from the Set Field Type field menu list.
description of choices available.
example, the AP:Signature Authority form.
authority data.
approval request).
7. Enter the name(s) of the fields to receive the data and the name(s) of the fields
where the data is located.
Example of a Get Authority Regular Rule

Figure 10-14 illustrates a typical Get Authority Regular rule. In this example, the
rule is defined to retrieve data for the person currently logged in and acting upon
the requisition ($Approver$ = LoginName). The value in this persons
DollarSigningAmount field from the AP-Sample:Signature Authority form will be
placed in a temporary field named TempReal 1.

The value in the temporary field is then available for use by Completion rules.
Figure 10-14 Get Authority Regular Rule Example
Working with Get Authority Self Rules

To create a Get Authority Self rule, use the following procedures.
Defining the Basic Data for a Get Authority Self Rule

Name field.
list.
Working with Get Authority Self Rules 10-25

4. Select Get Authority Self from the Rule Type field menu list.
appropriate fields for the Get Authority Self rule.
Qualification bar
Figure 10-15 Get Authority Self Basic Tab

Example of a Get Authority Self Rule on page 10-27 provides a look at a typical
Get Authority Self rule.
To complete the Get Authority Self rule continue, to the procedure for defining
the Set Fields Data.
Define the Set Fields Data for a Get Authority Self Rule
3. Select a value from the Set Field Type field menu list.
description of available choices.

example, the AP-Sample:Signature Authority form.
authority data.
approval request).
7. Enter the names of the fields to receive the data and the names of the fields where
the data is located.
Example of a Get Authority Self Rule

Figure 10-16 illustrates a typical Get Authority Self rule. In this example, the rule
is defined to retrieve data for the person currently logged in and acting upon the
approval request ($Approver$ = LoginName). The value in this persons
DollarSigningAmount field will be placed in a temporary field.
Working with Get Authority Self Rules 10-27

The value in the temporary field is then available for use by Self-Approval rules.
Figure 10-16 Get Authority Self Rule Example
Working with Completion Rules

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

To create a Completion rule, use the following procedures.
Defining a Completion Rule


Name field.
list.
4. Select Completion Rule from the Rule Type field menu list.
fields appropriate for a Completion rule.
Qualification bar
Figure 10-17 Completion Rule

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 may be left at zero.
7. Enter the rule condition in the Rule text box.
Example of a Completion Rule

Figure 10-18 illustrates a typical Completion rule. In this example, the condition
statement compares the value in a temporary field with the values in the
EstimatedTotal field on the approval request. If the condition passes, the approval
process is considered complete.
In this instance, the temporary field (TempReal1) 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.
Defining Routing Completion Rules 10-29

You must define a Get Authority or a Get Authority Regular rule for the
Completion rule to work correctly in this example.
Figure 10-18 Completion Rule
Working with Approval Process Done Rules

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

To create an Approval Process Done rule, use the procedures that follow.
Defining the Basic Data for an Approval Process Done Rule


Name field.
list.
4. Select Approval Process Done from the Rule Type field menu list.
As soon as you select a rule type, the AP:Rule Definition form changes to display
the fields appropriate for an Approval Process Done rule.
Figure 10-19 Approval Process Done basic Tab
5. Select a rule status in the Status field.

7. 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.
To complete the Approval Process Done Rule, continue to the procedure for
defining the Set Fields Data.
Defining the Set Fields Data for an Approval Process Done Rule
3. Select a value from the Set Field Type menu list.
Defining Approval Process Done Rules 10-31

description of the available values.
4. Type the appropriate Field Name and Value to change the status of the approval
request.
Example of an Approval Process Done Rule

Figure 10-20 illustrates a typical Approval Process Done rule. In this example, the
Approval Process Done rule activates when an approver marks the approval
request detail record Approved. The resulting action for this rule is that the
StateValue is changed to 40 (Approved).
Rule trigger
Rule assignment action
Figure 10-20 Approval Process Done
Working with Existing Rules

The following sections describe how to modify and delete existing approval rules.
Refer to the sections on specific rule types for detailed information on the field
requirements for specific rules.

Modifying Rules
Follow these steps to modify an existing rule.
Modifying a Rule
1. Select the Rule tab on the AP:Administration form and click the Refresh button.
A list of rules appears in a Query List window, as shown in Figure 10-21.
Figure 10-21 Rule List
2. Double-click a rule or select a rule and click the Open button.

The rule appears in a Modify Rule window and the current values for the rule are
shown.
3. Modify the appropriate rule fields by using the procedures described under the
specific rule type topics.
Deleting Rules
Follow these steps to delete an existing rule.
Note The delete operation is permanent and cannot be undone.
Be aware of any rule dependencies before deleting a rule. For example, Self-
Approval and Completion rules may 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.
Modifying Rules 10-33

Deleting a Rule
1. Follow steps 1 and 2 of Modifying Rules on page 10-33 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.

11 Managing Users and Roles Chapter
This chapter describes how to define user capabilities and roles for use by the
Approval Server in the approval process.
Defining Roles
Defining Alternate Approvers
Assigning Process Override Capability
11-1
Defining Roles
The following procedure takes you step-by-step through the fields on the AP:Role
form.
Defining a Role
1. Select Role on the AP:Administration form and click Create New.
Note See Using the Approval Administration Interface on page 8-2 to learn how to use
the AP:Administration form.
The AP:Role form appears.
Figure 11-1 AP:Role Form
1. Enter a Role Name in the Role Name field.

The name should be descriptive of a job or a responsibility. For example, MIS
Management would be more descriptive than just Managers (unless you
wanted to create a role that was inclusive of all managers in your company).
2. Select an option from the If Multiple Approvers field menu list.
11-2 Chapter 11 Managing Users and Roles

The option you select determines how many signature line records the Approval
Server creates for the role when building an Approver List. The options follow.
One Must Sign Use this value to create a single signature line record for the
role. The signature line is complete when one of the members
of the role acts upon the approval request.
All Must Sign 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 9-2 for more information on 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.
3. Select a value from the Status field menu list.

Select either Active or Inactive.
4. Type the names of individuals or roles to the Member List.
Type valid user names or roles in the Member List box, separating entries with a
semicolon or a hard return. Click the Text Box button to open an expanded text
box. This field has a maximum length of 255 characters.
5. Click the Save button to save the record.
Defining Roles 11-3

Defining Alternate Approvers
Use the procedure that follows to define an alternate using the AP:Alternate form.
Note Alternates must be licensed with change permissions. You should not make an
alternate of an individual who does not have this capability.
Defining an Alternate
1. Open a new AP:Alternate form. The AP:Alternate form appears.
Figure 11-2 Defining an alternate
2. Enter this alternates name in the Alternate field.

The name must be a valid user name.
3. Verify the user name in the For field.
This name defaults to the name of the current user, but it can be changed to
another name if you have the appropriate system capabilities, such as full process
administrator or AR System administrator.
4. Select one of the Covering option buttons.
All Use this option to authorize a user as alternate for all the
processes of the person indicated in the For field.
Specific Use this option to authorize a user as alternate for one specific
Process 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.
5. Type a date in the Start Date field.

Type a valid date or select a date from the menu list.
6. Type an End Date.

Type a valid date or select a date from the menu list.
7. Select a value form the Notify Alternate field menu list.
Select either Yes or No. If you select Yes, a notification is sent to both the person
identified and to anyone designated as an alternate for that person.
8. Click Save to save the Alternate information.
Assigning Process Override Capability

Use the procedure that follows to assign process administrator override
capabilities using the AP:Process Administrator form.
Assigning Override Capabilities

1. Open the AP:Administration form and click the Administrator tab.
2. Click Create New.
The AP:Process Administrator form appears.
Figure 11-3 Assigning Override Authority
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 No message is sent.
Notifier Specified users are notified when they run the Action Request
Notification Tool. For more information about the Notification
Tool, see the Remedy User online help.
Assigning Process Override Capability 11-5

E-Mail Specified users are notified using email.
User Default 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. Select a value from the Status field menu list.

Select either Active or Inactive.
7. Click one of the Covering option buttons.
All Use this option button to authorize a user as alternate for all
the processes of the person indicated in the For field.
Specific Use this option button to authorize a user as alternate for one
Process 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 the Save button to save the record.

12 Adding Approvals to Your
Application Chapter
This chapter describes how AR System administrators can connect AR System

applications to the Approval Server. This discussion assumes you have an
existing application, and have previously installed the Approval Server.
Connecting an Application to the Approval Server
Preparing Your Application for Approval Web
Note Although you do not have to be an AR System administrator to set up and manage
approval processes, you must be an AR System administrator to connect your application
to the Approval Server.
12-1
Connecting an Application to the Approval Server
Follow these steps to link your applications form to the Approval Server. The
examples in this chapter use xxx for the name of the application connected to the
Approval Server.
Usually you will link only the main form of your application to the Approval
Server. If your application has more than one form that needs to start an approval
process, you will need to join each form, as shown in steps 1 and 2.
Connecting Your Application to the Approval Server

1. As an AR System Administrator, launch Remedy Administrator.
2. Create an inner join with xxx as the Primary form and AP:Detail as the secondary
form.
a. Join Request ID field ID 1 of your form xxx to the Request field (field 8) of
form AP:Detail.
b. Include all fields from xxx form and all fields from AP:Detail.
c. Position the Status field ID 7 from AP:Detail in a prominent location so you
can modify it in step e.
Do not spend time arranging the positions of other fields. This join form is
generally used only for internal processing so the appearance of the form is
not critical.
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 Approval Central
properly.
Before you save your join form, you must manually specify a reserved ID for two
fields, as described in step e and step f.
e. Double click the Status 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.
f. Double click the Request field ID 8 from AP:Detail. Click the Database tab.
Type the number 10051 in the empty ID field.
g. Save your form.
h. Click OK both times when the AR System asks you to confirm your intention
to use reserved IDs.
12-2 Chapter 12 Adding Approvals to Your Application

3. 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 below can be modified only by the AR System administrator.
DB Default Allow Any User Default

ID Label Permissions to Submit Value
1 Request ID Assignee (view) No No

Public (view)
2 Submitter Assignee (view) Yes $\USER$

Public (view)
3 Create Date Assignee (view) No -

Public (view)
4 Assigned To Assignee (change) Yes $\USER$

Public (view)
5 Last Assignee (view) No -

Modified By
6 Modified Assignee (view) No -

Date
7 Status Assignee (write) Yes New

Public (view)
Submitter (write)
8 Short Assignee (write) Yes -

Description
Public (view)
Submitter(write)
4. Create an inner join between xxx and AP:Detail-Signature, with xxx as the
Primary form and AP:Detail-Signature as the secondary form.
a. Join Request ID field ID 1 of your form xxx to the Request field ID 10051 of
form AP:Detail-Signature.
b. Include all fields from xxx form and all fields from AP:Detail-Signature.
c. Double click the Status field ID 7 from AP:Detail. On the Display tab, change
the field access to Read/Write. Click the Database tab. Verify the number
13191 appears in the ID field.
d. Arrange the fields of this form with care.
Connecting an Application to the Approval Server 12-3

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 may hide or remove from view most of the fields of the AP:Detail-
Signature form. Display only those fields that are significant or that you want
your users to have access to.
Move the Status field ID 13191 to a prominent location, because this is the
field approvers use to approve or reject a request. You can optionally
rename this field to Approval Status in order to help approvers understand
its function.
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.
e. 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 Approval Central
properly.
While creating the join, you may 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 Remedy Administrator to suppress
this warning.
5. Once the joins are created, run the program arjoinfix (UNIX) or
arjoinfix.exe (Windows NT). Find this program in the same directory as the
AR System Approval Server program.
Note You must run arjoinfix (UNIX) or arjoinfix.exe (Windows NT) on all forms
you create for use with the Approval Server. This executable modifies the join qualifications
to ensure 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.
6. Launch 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. In order to perform this step, you must be a Process Administrator
with Full Admin authority for all processes (or an AR System Administrator).

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 Process,
Rules, Notifications, and Roles to handle all approval processes you planned in
the previous step.
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 may 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-Detail -s $SCHEMA$ -e
$Request ID$ -t ABC
Refer to Appendix C for details on Approval Server commands.
10. Create a Process Done rule, or your approved/rejected results will never be
reported to form xxx. This is very important.
Optionally, you can add links to stop a pending process or to provide more
information.
If you chain together more than one process, you should 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.
Connecting an Application to the Approval Server 12-5

Preparing Your Application for Approval Web
This section discusses how to prepare an application you previously linked to the
Approval Server for use within the Approval Server Web interface. This section
includes three topics:
Configuring Your Application for Approval Web
Enabling the Optional Password Field
Enabling Optional Diary Fields under ARWeb 3.x
Note These procedures require that you edit files in the web document directory of your
web server. You may need to get access permission from your web server administrator to
modify these files.
Configuring Your Application for Approval Web

The following steps allow approvers to access the Approval Server from the web.
Note The web interface allows approvers to process approval requests from a web
browser. Process administrators must use Remedy User to configure approval processes
and perform overrides.
1. Use a text editor, such as Wordpad, to make the following three changes to the file
config.html located in this directory:
<web server document directory>/esapps/approval
a. Copy the contents of config.html.template into your config.html
file. Paste the contents immediately in front of the </script> tag in your
config.html file. Then edit the settings according to the comments
appearing in the file.
b. At the top of the file, add this line after a block of similar lines already present
in the file:
var xxx_Inst=top.xxx_Inst
The xxx prefix is your application name. It is the same prefix that is on the
first line of the template that you loaded in step a.
c. Search for the string portaloc. Review the comments before this line and
update the line as appropriate to identify your home location. This is the
location the system will go to whenever the Home link is selected on any of
the Approval Server pages. This setting is common to ALL applications that
are using the Approval environment.
2. Use a text editor, such as Wordpad, to open the file appstart.html located in
this directory:

Add this line to the file:
var xxx_Inst=true
Use the name of your process instead of xxx. This line indicates that this
subsystem, your application, is active and should be included. Setting the value to
false or omitting it completely will disable your application on the web.
3. (This step is only for ARWeb 3.x configurations. Skip this step and perform step 4
if you have ARWeb 4.x.) Create a custom page for the three-way join between
your application and the AP:Detail-Signature form.
a. Run ARWeb within a browser.
b. Display your form in Query Mode.
c. Use the menu of your browser to View Source.
d. Copy the HTML source to a new text file.
e. Find the line in the file that says,
Cut this line and everything above it if you are creating a
custom form file.
Delete this line and everything preceding it from the source file.
f. Find the line in the file that says,
Cut this and everything below it if you are creating a custom
form file.
Delete this line and everything following it from the source file. Save the file
in a temporary location, as a text file with any name.
g. Create a directory under your server directory for the form.
Create the directory on your ARWeb Server, in a subdirectory of the forms
subdirectory that has the same name as your computer. For example:
C:\ARWeb\forms\<your_computer_name>\<your_app_xxx>
The name of the directory is critical. You must give the directory the name of
your parent application (xxx) using special characters. This is the name of the
form directory that is created by ARWeb. It is the name of the form with
appropriate substitutions for special characters.
You can ensure the correct name by opening the form connected to the
Approval Server in ARWeb, and copying the name from the filename created
for that form. For example, AP%3aLunch+Request is the name of the sample
Lunch Request application, as shown in the sample application form:
apconfig[indset][3]='AP%3aLunch+Request';
h. Copy the modify.for.template file from the base forms directory, rename
it modifyfo.for, and save it in the directory you created in step g.
i. Find the line within the modify.for file that says,
<!_****Paste in ARWeb Form File Here (Remove This line)****-->
Preparing Your Application for Approval Web 12-7

Delete this line and paste into this location the text from the new file you
created in step d.
This custom page makes the detail record available if you follow the link from the
Approval List to get more details on a specific item.
4. (This step is only for ARWeb 4.x configurations. Skip this step if you are using
ARWeb 3.x.)
a. Locate the template file with this name
yourserver_yourappjoinform_modifyfo.jsp.template
b. Copy this template file so that the new file is named:
[your server]_[your application join form]_modifyfo.jsp
for example, if your server was named acme and your join form was named
applicationx, the copy of the template would be named
acme_applicationx_modifyfo.jsp
Warning If your application join form has non-alphanumeric characters in its name, you
should replace them with a lowercase letter x. For example, for a form named
HPD:Help Desk on server acme, the template would be named
acme_HPDxHelpxDesk_modifyfor.jsp.
Enabling the Optional Password Field

This procedure is optional. These steps describe how to indicate whether the
password field is visible next to the Save button on the Approval List window.
Use this field if you require any approvers to enter a password before they can
approve or reject a request.
Note The password setting is a global setting that affects all processes. Turn this off only if
NO processes require passwords. If any process requires the password, you need to leave
this setting on. The field will show on all lists. The user does not have to enter a password
unless the process requires a password validation.
1. Use a text editor, such as Wordpad, to open the file appstart.html located in
this directory:
2. Add or edit the variable showpassword.
If you do not want the password field to appear in any Approval Server Web
application, add this line to the file:
showpassword=0
The password field will not be displayed. If you have a process that requires
password authentication, it cannot be used on the web.

If you want the password field to appear in all Approval Server Web
applications, add this line to the file:
showpassword=1
The field will be displayed. If your process does not require a password, values
entered into the field are ignored.
The location of the showpassword line within the file is not critical, but the setting
must appear alone on a line as shown.
Enabling Optional Diary Fields under ARWeb 3.x
Note Diary fields are always enabled under ARWeb 4.x.
This optional procedure is for users of ARWeb version 3.x. The following steps
describe how to allow approvers to view existing Diary data from the Comments
or Audit Trail fields.
1. Log in to the Remedy Administrator tool as AR System Administrator.
2. On the xxx-Detail-Signature form, copy your view to create a view named
webModify. On this view, make sure the fields from the AP:Detail form named
Comments Web and Audit Trail Web are in the view, but hidden.
3. Copy the active link AP-Sample:LoadDiaryOnDisplay filter. On the copy, change
the form to which the filter is attached to your xxx-Detail-Signature form.
4. In the custom modifyfo.for file you created (see earlier steps), find the
Comments field. It should appear similar to the following:
<TD VALIGN=top NOWRAP>Comments <textarea
onBlur=parent.blurHandler(this);
onKeyDown=parent.keyDown(event, this)
onChange='parent.onTextChangeHandler (this);' name=F13001F
wrap=virtual rows=3 cols=31>
Insert the contents of the file diary.for.template (in the same directory as the
modifyfo.for.template file) just before the word Comments. It is easiest if
you simply enter a return before the word comments and insert the file contents
on a separate line like the following:
<TD VALIGN=top NOWRAP>
Insert the contents of diary.for.template here.
Comments <textarea onBlur='parent.blurHandler(this);'
onKeyDown='parent.keyDown(event, this)'
onChange='parent.onTextChangeHandler (this);' name=F13001F
wrap=virtual rows=3 cols=31>
Preparing Your Application for Approval Web 12-9

5. Search forward for the Audit Trail field. Insert the contents of the file
diary.for.template as you did in the previous step. In the line inserted, you
will find about 80 characters in a clause that looks like the line that follows:
View_Diaries(APCOMMENTS)
Change APCOMMENTS to APAUDITTRAIL for the audit trail.
When you examine the web pages, an icon of an open book appears in front of the
Comments and Audit Trail fields. Clicking on that icon will display the existing
content of the associated field.
Note You can review the sample applications for examples of these edits.

13 Implementing Sample
Application Features Chapter
This chapter highlights features, in the sample application Lunch Scheduler, that
you can use in your own approval processes.
Overview of Lunch Scheduler
Key Forms
Sample Process Descriptions
Chaining Approval Processes
Restarting an Approval Process
Special Techniques
Sample Users
13-1
Overview of Lunch Scheduler
The Lunch Scheduler application is designed to schedule customer lunches for
employees of an imaginary company.
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:
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.
Major Account Level Approval is a review by the major and enterprise account
teams if the account is a major or enterprise account.
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.
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 NT) on all forms
you create for use with the Approval Server. This executable modifies the join qualifications
to ensure 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.
13-2 Chapter 13 Implementing Sample Application Features

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.
AP-Sample:Lunch-Detail-Signatu
This is the inner join between the AP-Sample:Lunch Scheduler and the AP:Detail-
Signature forms. This is the main working form for approvers who are approving
lunch requests. The join criteria is Request ID to Request.
AP-Sample:Company
This is a supporting form where companies and information about them is
entered. The data here drives menus and settings about the companies.
AP-Sample:Restaurant
This is a supporting form where restaurants and information about them is
entered. The data here drives menus and settings about the restaurants.
AP-Sample:Signature Authority
This is a supporting form where approvers and information about them is
entered. Information about managers is used to drive advancement along the
management chain. Information about their signature authority determines when
someone has sufficient authority to be the last person needing to sign. Account
Approval Level indicates whether someone is on the major or enterprise account
team and involved in the second stage approval process.
Sample Process Descriptions

Approving Lunch Scheduler requests requires three separate approval processes.
They are designed to run serially, and the latter two run conditionally, only if
required for a particular request.
This section discusses each processes as a stand-alone approval process. The next
section presents how to initiate the processes and how the application has been
set up to allow the processes to communicate among themselves.
AP-Sample:Lunch-Detail 13-3
Management Cost Authorization
This approval process runs first and acts on every request. This process is an
example of the Parent Child process type, with Auto Approval and Self
Approval rules. If requesters do not have authority, then the approval process
routes requests to their managers as identified in the AP:Signature Authority
form. The system continues to route to subsequent managers until a manager
with sufficient authority signs the request. If no one with sufficient authority can
be found for an individual, or if an individual has no manager, the process
terminates with an error.
The Management Cost Authorization process is launched by the filter AP-
Sample:StartCostApproval. The command within the filter is shown here:
Application-Command Approval New-Details -T
ManagementCostAuthorization
The tag argument identifies the process to run. Refer to New-Details on
page C-6 for more information on this Approval Server command.
Major Account Level Approval

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

This approval process runs only if the company currently has an overdue account.
This is an example of a rule-based process type. This process doesnt have a
standard style, instead it enforces the way in which approval is performed with a
custom style and criteria. This process includes an example of Prep Get Next
Approver rules used to set up the Get Next Approver processing.
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 AP-
Sample:StartOverdueApprov. The RunIf filter criteria must be met for this filter to
execute.

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

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

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

Using the Approval Workspace field, the system knows which process is active
and in progress, and can monitor the flow across three approval processes.
Note The Approval Workspace field is updated with a setting to indicate success of the
Major Account Level Approval process even when there is no action to be taken on the level
process. It is important that the process be marked successful in this case, so that the test
for the next process can simply be for approved or not approved, without having to worry
about how it got to the approved state.
Restarting an Approval Process

Occasionally, after an approval process has been started, it becomes inappropriate
to proceed. Situations and peoples minds often change, negating the needs of
yesterday. What if a request becomes unnecessary and you need to stop an
approval process?
This example has an automatic restart if there is a significant change to the
request. If anyone changes the restaurant, company, or number of attendees, the
automatic restart cancels the current process and routes it from the beginning.
This ensures that someone doesn't make a change after the record has already
been approved.
The way the example actually accomplishes this operation is to issue a cancel to
the approval subsystem. At this time, no further action is taken. The Done
processing of the processes will return Cancelled to the Approval Workspace field
discussed previously in Using a Status Field in Chained Processes. The
application watches for the Cancellation string and if that is set, will restart the
approval process from the beginning.
Special Techniques
This section introduces techniques that you may want to use in your own
approval processes. These techniques include:
More Information
Show Summary and Signatures
Show Password Field If Required
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 AP-
Sample: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 Remedy Administrator to review the button Manage More Information on
the AP-Sample:Lunch-Detail-Signatu form. Also review the active links AP-
Sample-Dtl-Sig:MoreInfo01 through AP-Sample-Dtl-Sig:MoreInfo06.
To take advantage of this extension in your own approval forms, follow this
procedure.
Adding a More Information Button

1. Create a button on your xxx-DetailSignature form, where xxx is your own
application.
The name of this button is not critical.
2. Give the button an ID of 13198 with public permission.
3. Make a copy of the six active links named AP-Sample-Dtl-Sig:MoreInfo01
through AP-Sample-Dtl-Sig:MoreInfo06.
4. For each copy, change the attached form to your xxx-DetailSignature join form.
Rename
Active Link
Attach to Your
Form xxx
Figure 13-1 Copy AP-Sample-Dtl-Sig: MoreInfo01 through MoreInfo06
Show Summary and Signatures

Some approvers want to see who has approved and who currently has the item
awaiting approval. The AP-Sample:Lunch Scheduler form has a pair of buttons
that allow someone approving a lunch request to get a list of signatures.
More Information 13-7

This extension is a relatively simple macro that receives parameters from the
current record. Copy the sample macros or create your own.
To create and activate Show Summary and Signatures, follow this procedure.
Adding Show Summary and Show Signature to Your Application

1. Create two buttons on your application form called Show Approval Summary
and Show Signature. Give these buttons Public permission.
2. Make copies of the following three active links :
AP-Sample:DisableShowOnCreate
AP-Sample:Show App Signatures
AP-Sample:Show App Summary
For each copy, change the attached form to your xxx-join form.
3. Export the three active links and edit them to match your application:
a. Substitute your database IDs for the two buttons.
b. Substitute the names of your Detail and Detail Signature forms for the Set-
Schema action of the macros.
c. Substitute your application name in the macro name.
4. Import the edited active links into your application.
Show Password Field If Required

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

1. Use Remedy Administrator to position the Password field ID 102 in an obvious
location on your xxx-Detail Signature join form.
2. Make copies of the following two active links:
AP-Sample:ShowPwdIfRequired1
AP-Sample:ShowPwdIfRequired2

3. For each copy, change the form to which they are attached to your xxx-Detail
Signature join form.
Recommended Technique: Menu of Valid Names

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

To log in with the sample login names, they must first be entered as valid
AR System users. Check with your AR System Administrator to determine if you
have purchased sufficient write licenses to create the sample users as actual
accounts in your AR System database.
Recommended Technique: Menu of Valid Names 13-9

If you prefer to use existing licenses with the sample applications, use the AP-
Sample:Signature Authority form to change the sample users to login names that
are already present within your AR System server User form.
Change
Sample
Names to
Licensed
Users
Figure 13-2 Use AP-Sample:Signature Authority to Change Sample Users
Sample User Approval Authority

The sample application users are set up in a parent child hierarchy with dollar
value spending authority shown in the following figure
Figure 13-3 Hierarchy and Spending Authority of Sample Users

A Installation and
Configuration Appendix
The AR System Approval Server is available for Windows NT and UNIX.

Installation directions for both versions appear in this appendix.
This chapter includes these sections:
Installation Notes and Warnings
Windows NT Installation
Windows NT Web Installation (Optional)
UNIX Installation
UNIX Web Installation (Optional)
Manually Starting and Stopping the Approval Server
ARWeb Configuration
Using an AR System Server Without Portmapper
Uninstalling the Approval Server
Where to Go Next
A-1
Installation Notes and Warnings
Warning Approval Server version 4 is incompatible with the version of Approval Server
bundled with certain Remedy applications. Do not install Approval Server version 4 on a
system with any of these Remedy applications:
Remedy Purchasing@Work 2.x, or earlier
Remedy SetUp@Work 1.0, or earlier
Remedy Change Management 3.x, or earlier
General Notes
You must be an AR System Administrator to install this product.
You should obtain a license for the Approval Server before you install.
Otherwise you must reboot or manually start the service (Windows) or daemon
(UNIX).
AR System Server Installation Notes

You must have AR System Server version 4.0.3 or later installed before you
proceed with the Approval Server installation. Approval Server 4.x is
supported on only AR System 4.0.3 or later.
You must install the Approval Server on your AR System server machine, and
the AR System server must be running during the Approval Server install
process.
If the Application Pending form is not already present on your AR System, you
must stop and restart the AR System Server before you can start using the
Approval Server.
The Approval Server is incompatible with the flat file database version of the
AR System server. The installer checks for this and terminates if the flat file
database is detected.
Approval Web Installation Notes

All Approval Web installations are optional.
You must have ARWeb 3.x, ARWeb 4.x, or both, installed before you install
Approval Web.
There are separate installers for ARWeb 3.x and 4.x. Be certain which version of
ARWeb you have if you install Approval Web.
A-2 Appendix A Installation and Configuration

If you have both ARWeb 3.x and 4.x on the same server, install the Approval
Web only for ARWeb 4.x, unless you have applications that require ARWeb 3.x.
Configurations of Approval Web for both ARWeb 3.x and 4.x on the same
server are not supported.
Warning If your web server fails to display Approval Web pages, verify the ARWeb server
is configured so the ARWeb\ENU directory has execute permissions.
If you configured your web server as shown in Appendix D of the ARWeb 4.0 Installation
and Getting Started Guide, the permissions for the ARWeb\ENU directory are set to
script rather than execute.
Approval Web Installation Notes A-3

Windows NT Installation
Use the following steps to install the Approval Server on a Windows NT
computer with an existing AR System installation version 4.5 or later.
You do not need to quit all applications before running the installer.
Installing the Approval Server on Windows NT

1. Insert the Approval server CD-ROM into your CD-ROM drive.
The CD Browser appears. If your computer is not set up to autorun CD-ROMs,
then use Windows Explorer to view the root directory of the CD-ROM and
double-click launch.exe.
Figure A-1 CD Browser Main Screen

2. Click the Install Products button.
The installer screen appears.
Figure A-2 CD Browser Installation Screen
3. Click the Approval Server button.

This launches the installer file. A dialog box asks you to select the language for
this installation.
Figure A-3 Select Installation Language
4. Select the language for this installation from the pull-down menu and click OK.
Windows NT Installation A-5

A splash screen appears and the installation shield begins. After a short delay a
welcome screen appears.
Figure A-4 Installer Welcome
5. Click Next.
The software license agreement appears.
Figure A-5 License Agreement

6. Click Yes if you agree to the terms.
A dialog box appears asking you for an AR System Administrator user name and
password.
Figure A-6 AR System Administrator Information
7. Type this information into the appropriate fields and click Next.
A dialog box appears asking for the path to install the Remedy Approval Server.
Figure A-7 Enter Installation Path

8. Click Next to use the default or click Browse to select another directory.
Remedy suggests you use the default to install in the same directory as the AR
System server.
9. Click Next to continue.
The installer asks if you want to install sample forms.
Figure A-8 Install Sample Forms Dialog Box
10. Click Yes to install forms and workflow for two sample applications that
demonstrate Approval Server features.
If you have never used or configured the Approval Server, Remedy recommends
you install and examine the samples. Refer to Chapter 6, Using a Sample
Application, and Chapter 13, Implementing Sample Application Features, for
information regarding these applications.
Progress windows appear to display the status of the installation.
The installer begins transferring data.
Figure A-9 Transferring Data Progress Bar
The installer begins checking for conflicts, examining your system for previous
versions of the Approval Server.
Figure A-10 Checking for Conflicts

The installer imports Approval Server forms and workflow. This could take
several minutes depending on the speed of your machine.
Figure A-11 Importing Forms and Workflow
Warning If you see a warning about new forms and workflow not matching the existing
ones, please verify that you do not have Remedy products installed that use an
incompatible version of the Approval Server. Refer to Installation Notes and Warnings on
page A-2 for a list of incompatible products.
If you see a message asking if you want to install new forms, click Yes to upgrade your
forms, or click No to use your old forms and preserve existing data.
The installer imports configuration data. This could take several minutes
depending on the speed of your machine.
Figure A-12 Importing Configuration Data
If you install the sample forms the installer checks for a previous installation of
the sample applications. The installer does not delete old sample applications.
You have to delete them from within the AR System.
Figure A-13 Installer Does Not Delete Old Sample Applications

If the installer detects no previous versions of the sample applications, installation
progress appears in the following two dialog boxes.
Figure A-14 Importing Sample Forms and Workflow
Figure A-15 Importing Sample Data
The installer starts the service required for the Approval Server.
Figure A-16 Starting Approval Server Option Service
The Installation Complete dialog box appears.
Figure A-17 Installation Complete
11. Click OK.

Usually you do not have to restart your machine to use the Approval Server. If
you do, a dialog box appears asking if you want to restart now.

You can now log on to the AR System to start using the Approval Server, or
continue to the next section to install Approval Web. Refer to the end of the
Installations for a roadmap for first-time process administrators.
Windows NT Web Installation (Optional)

Use the following steps to install Approval Server Web on a Windows NT
computer with AR System version 4.0.3 or later, and ARWeb version 3.0 or later
installed and running.
If you have ARWeb version 4.x, then you must install Approval Web 4.x.
If you have ARWeb version 3.x, then you must install Approval Web 3.x.
Installing Approval Web for Windows NT

1. Insert the Approval server CD-ROM into your CD-ROM drive.
If your computer is not set up to autorun CD-ROMs, then use Windows Explorer
to view the root directory of the CD-ROM and double-click launch.exe.
The CD Browser Main Menu appears.
Figure A-18 CD Browser Main Menu
Windows NT Web Installation (Optional) A-11

2. Click the Install Products button.
The Install Products screen appears.
Figure A-19 CD Browser Installation Screen
3. Click the button for the Approval Web installer you prefer.
The top button installs Approval Web 3.x for ARWeb 3.x
The bottom button installs Approval Web 4.x for ARWeb 4.x
Warning Do not install both versions of Approval Web on the same server. This
configuration is not supported.
A splash screen appears and the installer begins.

4. A welcome screen appears.
Figure A-20 Installer Welcome
5. Click Next.
The software license agreement appears.
Figure A-21 License Agreement

6. Click Yes if you agree to the terms.
A dialog box appears asking you to enter the name of your AR System Server.
This is the name of the machine where your AR System server resides, which is
not necessarily a web server.
Figure A-22 Enter AR System Server
7. Type the name of your AR System server and click Yes.

A dialog box appears verifying the port your web server uses.
Figure A-23 Verify Port Dialog Box

8. Click No if your server uses the default Port 80.
If you click Yes, a dialog box appears to ask you what port your web server uses.
Figure A-24 Specify Port Dialog Box
If you clicked Yes, you must type the number of the port and click Next.
A dialog box appears asking for the path to the directory where your web
documents are stored.
Figure A-25 Type Your Web Document Directory Path

9. Use the Browse button to select the directory.
For example, your web document path can appear similar to one of the following
default values:
Microsoft IIS default directory:
c:\inetpub\wwwroot
Netscape Suitespot 3.x default directory:
c:\netscape\suitespot\docs
Netscape Suitespot 4.x default directory:
c:\netscape\server4\docs
A dialog box appears asking you for the URL to your web document root
directory.
Figure A-26 Type the URL to Your Web Document Directory
10. Type the fully qualified URL in the field.
Warning Do not begin the URL with http:// and do not type a backslash at the end.
This is the URL that leads to the directory you selected in step 9. For example,
with a web server named acme, the fully qualified URL can appear similar to the
following:
acme.company.com

The installer begins transferring files.
Figure A-27 Transferring Files Progress Bar
After a few moments the installation is complete.
Figure A-28 Installation Complete
The Approval Server is ready to use as soon as the installation is completed.

continue to the next section to install Approval Web. Refer to the end of this
appendix s for guidance regarding what to read next for first-time Process
Administrators.

UNIX Installation
You must prepare all UNIX -based AR System servers with a simple procedure
before you install the Approval Server.
Preparing UNIX Servers for the Approval Server

Before installation on UNIX, verify the Public Group (0) Group Type is set to
Change. If this group does not have Change privileges, approvers will not have
write permissions required for the Approval Server forms.
Note You must perform the following procedure for all UNIX servers before you install the
Approval Server.
If you install the Approval Server without setting the Public Group (0) to Change
privilege, approvers cannot change any fields except the Approval Status field. In
this situation you must delete all Approval Server forms and menus, perform this
procedure, and re-install the Approval Server.
Setting Change Privileges for the Public Group

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

The Public Group appears.
Search for
Group ID 0
Verify
Change
Option
Is Set
Figure A-29 Verify Public Group 0
4. Verify that the Change option is set for the Group Type field.
If this option is not set, click the control for Change and then click Save.
Installing the Approval Server on UNIX Servers

Use the following steps to install the Approval Server on a UNIX workstation
with an existing AR System 4.0.2 or later installation.
Note Proceed with the UNIX installation only after completing the procedure Preparing
UNIX Servers for the Approval Server on page A-18.
You do not need to quit any applications before running the installer.
Running the Approval Server installation script

1. Change your current directory to the directory where you downloaded the
installation file. From this directory, run the script:
ar_apinstall
Installing the Approval Server on UNIX Servers A-19

2. The installer script asks
What is the AR System installation directory?
and provides a default directory if the installer finds your AR System installation.
Press Enter or type the proper directory and press Enter.
3. The installer script confirms the directory and asks
Is this OK?
Press Enter if the directory is correct, or type N to return to the previous step.
What is a valid AR System Administrator ID?
and provides a default if able. Press Enter to use the default, or type a valid
Administrator ID and press Enter.
5. The installer script confirms the Administrator ID, asking
<ID> is the AR System Administrator ID to use. Is this OK?
Press Enter if the ID is correct, or type N to return to the previous step.
What is the password for the AR System Administrator?
Type the password for this Administrator ID you provided, and press Enter.
Please re-enter the password for verification?
Type the password for the Administrator ID you provided, and press Enter.
What is the directory to install the Remedy 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.
9. 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
Remedy Approval Server will be installed in the <directory xxx>.
Is this OK?
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?
Press Enter or type Y to proceed. Type N to return to the previous step.

10. The installer script displays messages about the forms to install, and asks
Load Approval Server forms into the AR System? [y].
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.

Load Sample Application? [y].
Press Enter to continue, or type N to proceed with the installation without the
sample application.
If you have never used or configured the Approval Server, you should install and
examine the samples. Refer to Chapter 6, Using a Sample Application,and
Chapter 13, Implementing Sample Application Features, for information on the
sample applications.
The installer script displays many messages as it loads definitions of the Approval
Server forms into the AR System.
12. When you see the message
Loading...
you must press the Enter key or the installation script will appear to freeze.
13. When the installation is successful, the installer script reports
Remedy Approval Server installed.
The installer script executes the daemon for the Approval Server. The Approval
Server is ready to use as soon as the installation is completed.
continue to the next section to install Approval Web for UNIX. Refer to the end of
this appendix s for guidance regarding what to read next for first-time Process
Administrators.
Installing the Approval Server on UNIX Servers A-21

UNIX Web Installation (Optional)
Use the following steps to install Approval Server Web on a UNIX workstation.
Approval Server Web installation requires an existing AR System installation
version 4.0.2 or later, and an existing ARWeb installation version 3.0 or later.
Installing the Approval Server Web for UNIX

1. Change your current directory to the directory with the installation file. From this
directory, run one of these scripts:
ar_apwebinstall to install Approval Web for ARWeb 4.x
ar_apweb4install to install Approval Web for ARWeb 4.x
2. (This step applies only to Approval Web for ARWeb 3.x) The installer script
displays messages about disk space requirements and then asks
What is the system path to the CGI bin directory?
Type in your path; for example:
/usr/ar/arweb/cgi-bin
3. (This step applies only to Approval Web for ARWeb 3.x) The installer script
displays messages about disk space requirements and then asks
What is the system path to the ARWeb forms directory?
/usr/ar/arweb/forms
4. The installer script displays messages about disk space requirements and then
asks
What is the system path to the Web document directory?
/usr/netscape/suitespot/docs
5. The installer script displays messages about disk space requirements, warnings
about how to type a path, and then asks
What is the fully qualified URL path to the CGI bin directory?
acme.remedy.com/ars/cgi-bin
6. The installer script displays messages about how to type a path, and then asks
What is the fully qualified URL path to the Web document
directory?
acme.remedy.com

What is the name of the AR System server?
and provides a default value. Press Enter to accept the default value, or type the
name of the proper server and press Enter.
What is the name of the UNIX user used by the ARWeb executables?
Press Enter to accept the default value, or type the name of the user and press
Enter.
What is the name of the UNIX group used by the ARWeb executables?
Press Enter to accept the default value, or type the name of the group and press
Enter.
10. The installer script begins copying files. When the installation completes
successfully, the script displays the message:
Remedy Approval Application (Web) Installation Complete.
Manually Starting and Stopping the Approval Server

The installation procedures should automatically start the Approval Server
Windows service or UNIX daemon. However, if you have not obtained a license
before installation, you must manually start the Approval Server after obtaining
and entering the license key in the Remedy License application.
If you need to start the Approval Server manually, follow one of these procedures.
Starting the Windows NT Service
Starting the Approval Server under Windows NT

1. Open the Services control panel.
2. Select the Remedy Approval Server service.
3. Click the Start button.
If you want the Approval Server to start up each time the server reboots, verify
that the startup column entry is set to Automatic.
Stopping the Approval Server under Windows NT

1. Open the Services control panel.
2. Select the Remedy Approval Server service.
3. Click the Stop button.
Manually Starting and Stopping the Approval Server A-23

Starting the UNIX Daemon
Starting the Approval Server under UNIX

1. Make the current directory [install dir]/bin/arapprov.
2. Enter the command arapprov start on the UNIX command line.
Stopping the Approval Server under UNIX

1. Make the current directory [install dir]/bin/arapprov.
2. Enter the command arapprov stop on the UNIX command line.
ARWeb Configuration
Web Server Directory Permissions

If your web server fails to display Approval Web pages, verify the ARWeb server
is configured so the ARWeb\ENU directory has execute permissions. If you
configured your web server as shown in Appendix D of the ARWeb 4.0 Installation
and Getting Started Guide, the permissions for the ARWeb\ENU directory are set to
script rather than execute.
Under ARWeb 4.x you may additionally have to set permission within the
esapps/approval directory.
Note These are web server settings, not file system permissions. Refer to the
documentation for your web server administration software for the exact procedure to
change web directory permissions.
Setting Web Directory Permissions in Microsoft IIS

1. Launch IIS Internet Service Manager.
2. Locate the default web site ARWeb ENU directory.
3. Right click ENU and select Properties.
4. Select the Directory tab.
5. Under Permissions select the radio button for Execute (Including Script).
You may have to restart the web service before changes take effect.
Setting Web Directory Permissions in Netscape Enterprise Server

1. Launch Netscape Server Administration
2. Click on your server name.

3. Click Programs.
4. Click CGI File Type.
5. Select the Yes radio button under Activate CGI as a File Type.
6. Click OK to save your change.
If the Yes radio button was already selected, click OK when the message appears
telling you no changes have been made.
Using an AR System Server Without Portmapper

Without portmapper running, an AR System server requires manual port
configuration for communication with the Approval Server, Approval Web, and
ARWeb. For more information on portmapper, refer to Chapter the AR System
Server Administrators Guide. The following section discuss the procedures you
must perform for this configuration.
AR System server and Approval Server (required)
Approval Web 4 and ARWeb 4.x (optional)
Note The following procedures use example port number values. Your configuration can
use any port numbers that do not conflict with existing ports. You can discover your existing
ports in use with the command netstat -a (Windows) or rpcinfo -p (UNIX).
AR System Server Without Portmapper

Configuring AR Server 4.0.x
If you have AR System 4.5.x, refer to Configuring AR Server 4.5.x Without
Portmapper on page A-26. This procedure is for AR System server, version 4.0.x.
1. Open the file [ar_install]/conf/ar.cfg, (Windows) or arconfig (UNIX).
Note You must modify this file on each AR System server.to be used without portmapper.
2. Add the following lines to specify the port number.

TCD-Specific-Port: 9030
Admin-Specific-Port: 9031
Fast-Specific-Port: 9032
List-Specific-Port: 9033
Notifier-Specific-Port: 9034
Using an AR System Server Without Portmapper A-25

3. Add the following line to disable the portmapper.
Register-With-Portmapper: F
Keep this file open so you can change another line in the following procedure,
Configuring the Approval Server Without Portmapper.
Configuring AR Server 4.5.x Without Portmapper

If you have AR System 4.0.x. refer to Configuring AR Server 4.0.x on page A-25.
This procedure is for AR System server, version 4.5.x. With AR System server
4.5.x, you can use Remedy Administrator to disable the portmapper and to assign
one port number to the whole AR System server.
1. From Remedy Administrator, log on to the appropriate AR System server.
2. Open File Server Information Server Ports and Multiple Servers
3. Enter a port number in the Server TCP/IP field.
The example port number in these procedures is 9030.
4. Stop the AR System server and restart it.
The AR System server is listening on the ports now.
Approval Server Configuration

Configuring the Approval Server Without Portmapper
For the Approval Server to communicate with an AR System server, one entry has
to be added to the configuration file.
1. Open the file [ar_install]/conf/ar.cfg, (Windows) or arconfig
(UNIX).
Note You must modify this file on each AR System server.to be used without portmapper.
2. Add the following line to specify the port number.

Approval-Specific-Port: 9030
3. Stop and restart the Approval Server.
Refer to Manually Starting and Stopping the Approval Server on page A-23 for
the procedure. for Windows and UNIX.
Note If you do not use Approval Web then skip the steps Configuring Approval Web
Without Portmapper, and Configuring ARWeb 4.x without Portmapper.

Approval Web Configuration
Configuring Approval Web Without Portmapper
1. Open the following two files in a text editor:
[APWeb_install_dir]\esapps\approval\appcheck.html
[APWeb_install_dir]\esapps\approval\appstart.html.
2. In each file, find and change this line:
var Server_TCP_Port=0
to
var Server_TCP_Port=9030
If you use Approval Web, next you must configure ARWeb 4.0 to communicate
with this AR System server. Continue with Configuring ARWeb 4.x without
Portmapper.
ARWeb 4.x Configuration

Use the following procedures to configure Approval Web to communicate using a
non-default port with an AR System server without portmapper.
Configuring ARWeb 4.x without Portmapper

1. Open this file in your browser
http://[hostname]/arweb/enu/config/config.jsp
2. Click General Settings.
3. Click Edit AR Servers.
4. Click Add.
5. Type the AR System server name in the AR Server Name field.
6. Type the port number, 9030 in this example, in the Firewall Port Number field.
7. Click the Add AR Server button.
Approval Web is now ready for use without portmapper.
Approval Web Configuration A-27

Uninstalling the Approval Server
Removing a Windows Installation

To uninstall the Approval Server for Windows, use the Add/Remove Programs
control panel. Locate and remove both the Remedy Approval Server and the
Remedy Approval Service.
Removing a UNIX Installation

There are two executables for removing UNIX installations.
The Approval Server uninstaller ar_apuninstall is located in this
directory [install_dir]/approval/bin/
The Approval Web uninstaller ar_apwebuninstall is located in the web
directory specified during installation of Approval Web.
Warning The UNIX uninstallers reference other files relative to their own directories. Set
the current directory to the one in which the uninstaller executable resides.
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
Refer to Chapter 1, Understanding the Approval Process for basic Approval
Server concepts. Refer to Chapter 7, The Process Administrators Guide for
process administration concepts.
Refer to Chapter 6, Using a Sample Application for a demonstration of
acting as an approver using one of the sample applications. Refer to
Chapter 13, Implementing Sample Application Features for a demonstration
of process administration using one of the sample applications.
Refer to Chapter 12, Adding Approvals to Your Application for instructions
on how AR System administrators configure the Approval Server to work with
existing applications.

B Worksheets Appendix
The worksheets in this appendix are intended to assist you in designing the
various components of Approval Server. Reproduce the worksheets as needed.
The available worksheets are:
Process Worksheets
Rule Worksheets
B-1
Process Worksheets
The following process worksheets help you set up your process and escalations.
Defining a Process
More Information Escalations
Signature Escalations
Defining a Process
Use this worksheet to help you design a process.
Process Name
Process Type
Approval Success No more approvals Completion rule
If Multiple Approvers One must sign All must sign

Allow only one approver
Allow Ad Hoc? Anyone Approver No
Request Owner Field
First Approver Field
Validate Approvers Yes No
Require Password Yes No
Self Assignment Use Get Next Approver Rules

Assign to Owner If Approver
Always Assign to Owner
More Information Escalations

Use this worksheet to help you set the More Information state escalations
parameters on the Process form.
Workday Schedule
Holiday Schedule
Global Notifications
First Interval Unit
Repeat Interval Unit
B-2 Appendix B Worksheets

Signature Escalations
Use the following worksheets to help you set the Notification parameters on the
Process form.
Normal Priority Notifications
Workday Schedule
Holiday Schedule
Automatic Action
First Interval Unit
Change State Pending Approved Rejected
First Interval Unit
Pending State Notifications
First Interval Unit
Error State Notifications
First Interval Unit
Hold State Notifications
First Interval Unit
More Information State Notifications
First Interval Unit
Signature Escalations B-3

Urgent Priority Notifications
Workday Schedule
Holiday Schedule
Automatic Action
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit

Low Priority Notifications
Workday Schedule
Holiday Schedule
Automatic Action
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
Signature Escalations B-5

Rule Worksheets
The following worksheets help you set up your rules.
Auto-Approval Rules
Get Authority Self Rules
Get Authority Rules
Self-Approval Rules
Validate Approver Rules
Prep Next Approver Rules
Get Next Approver Rules
Completion Rules
Approval Process Done Rules

Auto-Approval Rules
Rule Name
Purpose
Condition
Audit Trail
Message
Get Authority Self Rules

Rule Name
Purpose
Run If
Statement
Set Fields Type Value Query SQL Process Other
From Form
Qualification
Set Field Value
Auto-Approval Rules B-7

Get Authority Rules
Rule Name
Purpose
Run If
Statement
From Form
Qualification
Set Field Value
Self-Approval Rules
Rule Name
Purpose
Condition
Audit Trail
Message
Validate Approver Rules

Rule Name
Purpose
Run If
From Form
Qualification

Prep Next Approver Rules
Rule Name
Purpose
Run If
Statement
From Form
Qualification
Set Field Value
Get Next Approver Rules

Rule Name
Purpose
If Multiple Value from first Values from all

Rows?
Return error clear
If Multiple One must sign All must sign clear

Approvers?
Next Approver? Additive Ending Exclusive clear
Run If
Statement
From Form
Qualification
Set Field Value
Prep Next Approver Rules B-9

Rule Name
Purpose
Run If
Statement
From Form
Qualification
Set Field Value
Completion Rules
Rule Name
Purpose
Condition
Approval Process Done Rules

Rule Name
Purpose
Condition Approved Rejected Cancelled Error
From Form
Set Field Value

C Application Commands Appendix
To support close interaction between the AR System server and the Approval
Server, a special process, Application-Command, has been introduced. This
process can be run from filters, escalations, and active links using the Run
Process action.
This appendix has two sections
Basic Information
Specific Approval Server Commands
C-1
Basic Information
The new process that has been introduced is Application-Command. This
command allows the specification of commands to be executed by an application.
There is a special form named Application Pending that 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.
The following list defines each parameter:
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.
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.
C-2 Appendix C Application Commands

command.
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. We suggest you always use quotes around
arguments to insure that they are processed correctly when they contain spaces.
Basic Information C-3

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

Application-Command Approval, according to the format described in
Basic Information.
Add-Sig
Add-Sig {-s form} {-e request-id} [-t process-name] {-o
approver-list} [-1 {0|1}] [-2 {0|1|2|999}]
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 required, because 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 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.
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-id parameters identify the request that the detail record
is associated with.
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]
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.
is associated with.
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
Done phase notifies the associated request of the error. This command is intended
only to be used internally by Approval Server.
is associated with.
Det-Cancelled C-5
Det-Rejected
Det-Rejected {-s form} {-e request-id} [-t process-name]
This command marks the approval detail item Rejected. Any outstanding
Done phase notifies the associated request of the rejection. This command
corresponds to a rejection by global override.
is associated with.
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 the ID of the More Information record.
New-Details
New-Details {-s form} {-e request-id} [-t process-name] [-1
priority]
This command starts the Approval Server process for the specified request.
The form and request to be approved are required because 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 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 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.
Rename-Form
Rename-Form {-t old-name} {-o new-name} [-1 only-active] [-2
do-rename]
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 Remedy
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.
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.
Rename-Form C-7
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.
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 form-AP:Detail-
Signature join.
The request-id parameter is the ID of an AP:Signature form request.
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.
Sig-Notify-Change
Sig-Notify-Change [-s form] {-e entry-id}
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 entry-id parameters are required. They identify the entry that is
to be notified.

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]
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 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.
Sig-Notify-State C-9
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.
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.
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.

D Approval Forms Appendix
This appendix displays Approval Server forms and provides field descriptions. The
forms appear in alphabetical order.
Approval Central
AP:Administration
AP:Alternate
AP:Detail
AP:Detail-Signature
AP:Form
AP:More Information
AP:Notification
AP:Process Administrator
AP:Process Definition
AP:Reserved Word
AP:Role
AP:Rule Definition
AP:Signature
Business Time Holidays
Business Time Workdays
User Form xxx
D-1
Approval Central
Approvers use this form as a launch pad to review their own approval requests
and More Information requests. All fields are optional except the Application
field.
Refer to Chapter 4, Processing Approval Requests with Remedy User for a
discussion of how to use this form.
Figure D-1 Approval Central Form
Application Use the menu list to select the AR System application with
workflow to be approved. This is a required field when
searching for approvals.
Request Use this field to search for a specific approval request using its
AR System ID.
Approval Status Use the menu list to select a status for a search. Leave the field
empty to view all your approvals.
Acting As Use this option button to select the capacity you are acting in.
Myself means you are working as yourself.
Alternate means you are working as a representative of

someone who has designated you as alternate.
Override means you are working as process administrator
to override the signature of a specific individual.
Global Override means you are working as process
administrator to override all signatures and take action on a
process itself.
User This is the name of the user you are acting as. This field is
ignored during global overrides.
Process Use the menu list to select a process from the application
selected in the Application field above.
D-2 Appendix D Approval Forms

View Approvals Click this button to search for approvals that match the criteria
entered in the other fields on this form.
My More Click this button to search for open More Information requests
Information that are awaiting your response.
Requests
Application Click this button to open a search window for the form specified
Approval in the Approver Reporting field in AP:Form.
Search
This button appears only when a form is defined in the
Approver Reporting field in AP:Form on page D-15.
AP:Administration
Process administrators use this form as a launch pad to create and modify records
that make up approval processes. Refer to Using the Approval Administration
Interface on page 8-2 for a discussion about using this form.
Figure D-2 AP:Administration Form
Create Click this button to create a new item of the category

determined by the current tab.
Open Click this button to open the item selected.
Refresh Click this button to have the AR System reload the displayed
list.
Search Click this button to open a search form for items of the category
determined by the current tab.
AP:Administration D-3
Delete Click this button to discard the currently selected item. It opens
the form that appears in AP:Admin-DeleteVerify on page D-4.
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.
Rename Click this button to open the form that appears in AP:Admin-
Rename on page D-5 to rename the currently selected item.
Process, Click a tab to display a list of items of that type. This also
Rule, selects which category of items is involved when you click the
Notification, buttons on this form.
Role,
Form,
Administrator,
Alternate
AP:Admin-DeleteVerify
This dialog box appears when a process administrator clicks the delete button on
the AP:Administrator form.
Figure D-3 AP:Admin-DeleteVerify Dialog Box Form
Yes Click this button to delete the item selected in the previous
form.
No Click this button to close the form with no action performed.

AP:Admin-Rename
This dialog box appears when a process administrator selects Approval menu
Rename.
Figure D-4 AP:Admin-Rename Dialog Box
Rename Click this option button to determine whether this rename

operation is performed on a form or a process.
From Old Name Type a name or use the menu list to select an item to be
renamed.
To New Name Type the replacement name for the item in the From Old Name
field.
Update Click this option button to determine which of the associated

detail records are renamed.
All renames detail records for current and past approval
requests.
Only Active Objects renames detail records only for
currently open approval requests.
Including Click this option button to include the form or process you are
Object Itself renaming. Generally this option is on.
This is useful if you are renaming all references to the name of
an item that has been manually renamed previously.
Perform Click this button to complete this rename operation.

Rename
Cancel Click this button to close the form with no action performed.
Note If you renamed a process manually instead of using the Rename dialog box, the
Rename command wont change names of attached rules. You must restore the process
name manually and then rename the entire process.
AP:Admin-ServerSettings
Process administrators use this form to change server settings regarding the
Approval Server. To open this form choose Approval menu Server Settings.
This custom menu appears when a process administrator views the
AP:Administrator form.
Figure D-5 AP:Admin-ServerSettings Form, Basic Tab
Debug Mode Click this option button to enable the Debug mode, which
creates entries in the log file.
Log Filename Type the directory path and file name in which to store log
entries for the Debug mode.
Definition Type a number of seconds in this field to determine how often

Check Interval 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 Type the RPC socket number of a dedicated private server to

Server RPC use when accessing the AR System Server.
Socket
Leave this field empty if you do not have a dedicated private
server.

Virtual Web Type the path for the directory where ARWeb forms are stored.
Document
Directory
OK Click this button to apply changes.
Reload Click this button to reload the form with previously stored
values.
Cancel Click this button to close the dialog box without saving
changes.
Figure D-6 AP:Admin-ServerSettings Form, Notification Tab
New Signature, On the Notification tab, click Enabled next to an event to have
Approve, the AR System issue a notification when such an event occurs.
Reject, Disabled means Approval Server disables notifications for
Alternate this event during an approval process.
Approve, Enabled means the Approval Server enables notifications
Alternate for the approver list when this event occurs during an
Reject, Override approval process.
Approve,
Enabled Including Alternate means the Approval Server
Override Reject,
enables notifications to approver list as well as all active
Close Approve,
alternates when this event occurs during an approval
Close Reject,
process.
Reassign, Error,
Cancel, More These option buttons do not guarantee notifications occur for
Info Return, an enabled event. These settings enable notification as
Reject by Later established elsewhere in the process rules.
Level, Cancel at
Later Level,
Reject by
Another
Approver, Hold,
More Info,
Change After
Approval
Figure D-7 AP:Admin-ServerSettings Form, Escalations Tab

Still Active, Still On the Escalation tab, click Enabled next to an event to have
Active (repeat), the AR System issue an escalation when such an event
Still Pending, occurs.
Still Pending Disabled means Approval Server disables escalations for
(repeat), Still this event during an approval process.
Hold, Still Hold Enabled means the Approval Server enables escalations for
(repeat), Still the approver list when this event occurs during an approval
More Info, Still process.
More Info
Enabled Including Alternate means the Approval Server
(repeat), Still
enables escalations to approver list as well all active
Error, Still Error
alternates when this event occurs during an approval
(repeat)
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:Alternate
Approvers use this form to create, delete, and maintain alternates.
Figure D-8 AP:Alternate Form, Alternate Information Tab
Alternate Type the name of the individual who is to receive the

administrative privileges.
For Type the name of the person for whom the Alternate will
substitute.
Covering Click this option button 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
below.
AP:Alternate D-9
Process Enter the process for which the alternate has authority. Use the
menu list to ensure you select only a process that exists on this
server.
Start Date Click the calendar menu to select the date on which the
alternates authority begins.
End Date Click the calendar menu 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.
Status 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.
Figure D-9 AP:Alternate Form, Administrative Information Tab
Alternate ID The AR System populates this field with an AR System ID for

this record.
Last Modified The AR System populates this field with the name of the
person who last modified this alternate.
Help Text Type information to aid users who are setting up alternates.
Change History Type any additional information to be recorded with the

alternate assignment. This information becomes part of the
permanent record for this alternate.

Assigned To Type the name of the original approver assigning authority to
this alternate.
Create Date The AR System populates this field with the date this alternate
was created.
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.
Figure D-10 AP:Detail Form
Application The AR System populates this field the name of the

AR System application to be approved with this request.
Request The AR System populates this field with the AR System ID for
the request.
Process The AR System populates this field with the name of the
approval process of this request.
Comments Type any additional information to be recorded with the

permanent record for this request.
Priority Use the menu list to select the priority attached to this request.
Each process defines the meaning behind Urgent, Normal,
and Low.
Submitter The AR System populates this field with the name of the
person who requested the workflow to be approved.
Status The AR System populates this field with the status of the
request.
AP:Detail D-11
Approval Audit This field contains an audit trail of date, time, and approver
Trail when approval activity occurs to this request. This information
becomes part of the permanent record for this request.
Global Approve Click this button to approve the request, overriding the regular
approval process. You must have process administrator
override authority to perform this action.
Global Reject Click this button to reject the request, overriding the regular
approval process. You must have process administrator
override authority to perform this action.
AP:Detail-Signature
Process Administrators use this form to track the history of responses to an
approval request.
Figure D-11 AP:Detail-Signature Form

Approval Status Use the menu list to select the status of the request.
Pending means the Approval Server is waiting for a
response to a request in progress.
Approved means you approve the workflow associated with
this request.
Rejected means you do not allow the workflow to be
approved, cancelling the request entirely.
Hold means you are associated with this request but no
Approval Server actions occur.
More Information means you need the original requester 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.
Password Type your password for verification. The Approval Server

verifies the contents of this field before a save operation
occurs.
This field appears only during Search and Modify, not when the
record is created.
Approval Use the menu list to select the priority attached to this request.
Priority Each process defines the meaning behind Urgent, Normal
and Low.
Comments Type any additional information to be recorded with the

permanent record for this alternate.
Next Approver Type the name(s) of the next approver(s) to see this request.
If Multiple Select how the approval process operates when many

Approvers 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 Type the name of an approver to whom you want to reassign

this request.
Approvers The AR System populates this field with the names of persons
who have already approved this request.
AP:Detail-Signature D-13
Approval Audit This field contains an audit trail of date, time, and approver
Trail when approval activity occurs to this request. This information
Application The AR System populates this field with the name of the AR
System application workflow to be approved with this request.
the request.
Process The AR System populates this field with the name of the
approval process of this request.
Submitter The AR System populates this field with the name of the
person who originated this request.
Approver This field contains the name of the approver of this request.
Signature The name appears only after an authorized person modifies
the Approval Status field.
Alternate This field contains the name of the alternate approver who
Signature modifies the Approval Status field.
More This field contains any requests for more information and the
Information responses when they occur to this request. This information
Show Details Click this button to open the form for the workflow the requester
wants to be approved.
More Click this button to open the More Information form with which
Information you can request additional information.
AP:Dtl-Sig-MoreInfoDialog
Approvers use this dialog box to examine More Information records. To access
this dialog box click the More Information button on the AP:Detail Signature
form.
Figure D-12 AP:Dtl-Sig-MoreInfoDialog Form

Existing More This field displays any More Information records attached to
Information the current approval process. Click on a header to sort
Records information by that column.
Create a New Use this button to open the More Information form and create a
new More Information record.
Open Click this button to open the currently selected item in the field
above.
Cancel Click this button to close the form.
AP:Form
Process Administrators use this form to attach forms to an Approval Server
process.
Figure D-13 AP:Form Form, Form Tab
Form Name Type a form name or use the menu list to select a form on the
current server.
Lookup Type a keyword to enable easy identification when searching

Keyword for this form.
Used By Type the name of the AR System application that uses the
form.
Approval Type the name of a form or use the menu list to select a form
Reporting that users may search using the Application Approval Search
button described on Approval Central on page D-2.
Approval Reporting is an optional field.
Refer to the description of Figure D-9 on page D-10 for field definitions of the
Administrative Information tab.
AP:Form D-15
AP:More Information
Approvers use this form to ask questions about a request.
Figure D-14 AP:More Information Form
To Type the name of the person you want the Approval Server to
ask for more Information. Unlike some fields, this field can
contain only one name.
From Type the name of the person who is asking for more
information. This field is read-only once the record is saved.
Status Use the menu list to select the status of the approval request
that this More Information record is attached to.
Question Type the question regarding the information you want.

Response Type additional information regarding this More Information
record.
Application The AR System populates this field with the name of the AR
System application workflow that needs to be approved with
this request.
this request.
Open Related Click this button to open the form for the AR System application
that needs to be approved.

AP:Notification
Process administrators use this form to create and modify notifications sent by
approval processes.
Figure D-15 AP:Notification Form, Description Tab
Notification Type a name for the notification.

Name
Process Name Type the name of the process.
Status Use the menu list to select the status of the notification.
Active
Inactive
AP:Notification D-17
Figure D-16 AP:Notification Form, Qualification Tab
Notify On Use the menu list to select an event in the approval process
that triggers this notification.
Additional Type additional qualifiers to the event that triggers this

Conditions notification.
Figure D-17
Figure D-18 AP:Notification Form, Details Tab

Method Use the menu list to determine the manner of notification.
None sends no notification message.
Notifier notifies this person with the Action Request

Notification Tool.
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.
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 AR System
keywords for notification recipients.
Subject Type a subject line for the notification message. Use the menu
list to select AR System variables to add to the subject.
Additional Use the menu list to select AR System variables to add to the
Fields 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.
AP:Notification D-19
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. Refer to Setting Up
Administrator Capabilities on page 8-6 for a discussion of this form.
Note The first process administrator must be created by your AR System Administrator.
Figure D-19 AP:Process Administrator Form, Process Administrator Tab
Individual This field contains the user name of the individual who is to be
a process administrator.
Authority Use the menu list to select the privileges allocated to the
individual in the field above.
Full Admin grants this person full authority as a process
administrator.
Override Only Admin grants this person only the authority
to override a process.
Notify Method Use the menu list to determine the manner of notification.
None sends no notification message.
Notifier notifies this person with the Action Request

Notification Tool.
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.
Status Use the menu list to determine the status of this persons
process administration privileges.
Active
Inactive

Covering Click this option button to determine the process(es) for which
this person receives process administrator privileges.
All
Specific Process
Process Name Use the menu list to select a process name if you selected
Specific Process in the Covering field above.
AP:Process Definition
Process administrators use this form to create and modify approval processes.
Refer to Using the Process Definition Form on page 9-2 for a discussion about
using this form.
Figure D-20 AP:Process Definition Form: Process Definition Tab
Process Type the name of this process.
Application Type the name of the AR System application with workflow to

be approved by this process.
Type Use the menu list to select the process type for this process.
Refer to Approval Process Types on page 7-17 for a
description of approval process types.
AP:Process Definition D-21

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 above.
Inactive means this process is disabled and generates no
approvals for any application.
Request Owner Type a valid user name or use the menu list to select the owner
Field of a request in this approval process.
First Approver Type in the name or use the menu list to select the approver to
Field 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 Use the menu list to select the manner with which the Approval
Success 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 Use the menu list to select the number of signatures required
Approvers 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 Use the menu list to determine who can select an Ad Hoc next
Next Approver? approver.
Anyone means the requester and any approver can select
an Ad Hoc next approver.
Approver means any approver can select an Ad Hoc next
approver.
No one means this process never allows an Ad Hoc next
approver.

For Self Use the menu list to select what happens when the person who
Assignment initiated the approval is not the owner of the request.
User Get Next Approver uses the standard rules of the
process.
Assign to Owner if Approver assigns the entry to the
owner of the request if that person is an approver. The
Approval Server checks the Validate User rules to determine
if the person is an approver.
Always assign to Owner assigns the entry to the owner for
approval if this person did not request this approval.
Validate Use the menu list to determine Yes or No, whether Ad Hoc
Approvers? next approvers are validated before they can respond to a
request.
Require Use the menu list to determine Yes or No, whether the
Password? approver must enter a password to save changes to an
approval request.
Figure D-21 Process Definition Form: Signature Escalations Tab
The three tabs on the Signature Escalation tab contain identical fields.
Workday Use the menu list to select a schedule created on the form,
Schedule Business Time Workdays on page D-32.
Holiday Use the menu list to select a schedule created on the form,
Schedule Business Time Holidays on page D-31.

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.
Unit Select the unit of Hours or Days as the unit for the interval in
the previous field.
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.
First Interval Type a numeric value for the amount of time to pass before this
notification first occurs
Unit Select the unit of Hours or days for the interval in the previous
field.
Repeat Interval Type a numeric value for the amount of time to pass before this
notification recurs. For example, type a 2 for two hours or two
field.
On Save Set the separate escalation and repeat intervals to occur when
a form is saved with the status of Pending, Error, Hold, or More
Information.
notification first occurs. For example, type a 2 for two hours or
two days. The unit is determined in the next field.
Unit Select the unit of Hours or Days for the interval in the previous
field.
notification recurs. For example, type a 2 for two hours or two
Unit Select the unit of Hours or Days for the interval in the previous
field.

Figure D-22 AP:Process Definition Form, More Information Escalations Tab
Workday Use the menu list to select a schedule created on the form,
Schedule Business Time Workdays on page D-32.
Holiday Use the menu list to select a schedule created on the form,
Schedule Business Time Holidays on page D-31.
action first occurs. For example, type a 2 for two hours or two
field.
action recurs. For example, type a 2 for two hours or two days.
The unit is determined in the next field.
field.

AP:Reserved Word
Process Administrators use this form to create keywords and functions for
approval processes.
Figure D-23 AP:Reserved Word Form
Name Type the name of the word you want to reserve.
Name Type Click the option button to select whether the word is a keyword
or function.
AP:Role
Process administrators use this form to create roles within approval processes.
Refer to Defining Roles on page 11-2 for a discussion about using this form.
Figure D-24 AP:Role Form, Role Information Tab

Role Name Type the name for this role.
If Multiple Use the menu list to select how the approval process operates
Approvers when many approvers appear in the Member List field.
required from everyone indicated in the Member List field.
Member List field must approve the request.
This field is valid only if there is more than one entry in the
Member List field.
Status Use the menu list to select the status of this role.
Active means this role currently can be used by any
approval process.
Inactive means this role is disabled for all approval
processes.
Member List Type the user name for each person to participate as a
member of this role.
AP:Rule Definition
Process administrators use this form to create and modify rules for approval
processes. Refer to The Rule Definition Form on page 10-2 for a discussion
about using this form.
Figure D-25 AP:Rule Definition Form, Basic Tab
Rule Name Type a name for this rule.
For Process Use the menu list to select a process for this rule.
AP:Rule Definition D-27

Rule Type Use the menu list to select the rule type. Refer to Chapter 10,
Defining Approval Rules for a discussion of rule types.
Status Use the menu list to select the status of this rule.
Order Type a number to determine execution order for this rule.

Larger numbers fire after smaller numbers. Rules with the
same number in this field execute in an unpredictable order.
Rule Type the rule here. Use the buttons and menu list to help. Refer
to The Rule Definition Form on page 10-2 for a discussion of
creating rules.
Audit Trail Type any text you want to appear the permanent record for the
request whenever this rule executes. Use the menu list to
select keywords to include in your audit trail message.
If Multiple Rows Use the menu list to select the behavior when there are
multiple rows.
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 Use the menu list to select the behavior when there are
Approvers 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 Use the menu list to select the behavior when there are
Rule Is 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.

Figure D-26 AP:Rule Definition Form, Set Fields Tab
Set Fields Type Use the menu list to select how this rule will populate a field.
From Form 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.
On Server Use the menu list to select the server that contains.
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.
Server Type the name of the server that holds the form. This field is
available only when the On Server field contains the value
Alternate.
Separator Type the letters, numbers, or symbols to use when separating

String multiple entries set in the same field. This field is disabled with
some options available in the Set Field Type field.
AP:Rule Definition D-29

Qualification Type a qualification or use the menu list to select AR System
functions or keywords. The Qualification field is disabled with
some options available in the Set Field Type field.
Field Name Type a field name or use the menu list to select a field name.
The Field Name field is disabled with some options available in
the Set Field Type field.
One rule can populate more than one field by using separate
lines for Field Name and Value.
Value Type the value to use for populating the field. The Value field is
disabled with some options available in the Set Field Type field.
One rule can populate more than one field by using separate
lines for Field Name and Value.
AP:Signature
Approvers use this form to review the responses to a request.
Figure D-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
Information answers to More Information requests.
Approval Status The AR System populates this field with the status of the
request.

Next Approver The AR System populates this field in an Ad Hoc situation with
the name of the next approver.
If Multiple This option button is valid only if there is more than one entry in
Approvers the Next Approver field.
required from everyone indicated in the Next Approver field.
Next Approver field must approve the request.
Alternate The AR System populates this field with your name if you are
Signature acting as alternate for this approval.
Approver Type the name of a valid approver to respond to this request.

Signature
Signature The AR System populates this field with the method by which
Method 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.
Business Time Holidays

Process Administrators use this form to determine the business holidays for use
by approval processes and other AR System workflow.
Figure D-28 Business Time Holidays Form, Holiday Definition Tab
Business Time Holidays D-31

Tag Type a unique name for this holiday period.
Holidays Type the date(s) included in this holiday period in the normal
AR System format.
Business Time Workdays

Process Administrators use this form to determine the hours of business for use
by approval processes and other AR System workflow.
Figure D-29 Business Time Workdays Form, Workdays Tab
Tag Type a unique name for this holiday period.
Open Time 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 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.

User Form xxx
In general, there are no requirements on the users form for which the approval is
requested. However, two temporary fields are required to allow the launching of
the approval processing:
Added fields:
Display-only integer field to hold a status value.
Display-only character field (255 bytes) to hold a path name to a program.
You will need a filter or active link to initiate the approval process.
If your user form requires multiple approval processes, you should include filters
to allow launching and handling of the various processes, as well as additional
fields to track status. For example, if you have a Computer Purchase Request, it
may need approval by a management group, an MIS group, and a purchasing
group. Requesters would find it useful to have status fields that indicate which of
these separate approvals have completed.
User Form xxx D-33

E Troubleshooting Appendix
This appendix contains troubleshooting information for the Remedy Approval

Server, grouped in these categories.
Installation Concerns
Approval Web Concerns
Sample Application Concerns
Miscellaneous Runtime Concerns
E-1
Installation Concerns
This section discusses known concerns regarding Approval Server installation.
Previous Approval Server Installations

Warning Action Request System is incompatible with the version of Approval Server
bundled with certain Remedy applications. Do not install Action Request System on a
system with any of these Remedy applications:
Remedy Purchasing@Work 2.x, or earlier
Remedy SetUp@Work 1.0, or earlier
Remedy Change Management 3.x, or earlier
Installer Terminates While Checking for Conflicts

If the installation terminates unexpectedly while the installer is checking for
conflicts, verify whether you have previously installed the Approval Server or an
application that includes a bundled Approval Server. You may have to uninstall
the previous installation before you can proceed.
Back Up Customized Workflow

If you have customized a previous Approval Server installation, or customized an
application that includes a bundled Approval Server, you should back up your
customized forms, HTML files, and workflow before installation.
Licensing
If you do not license the Approval Server before installation, you must reboot, or
manually restart the service (Windows) or daemon (UNIX). Refer to Manually
Starting and Stopping the Approval Server on page A-23.
Application Pending Form

If the Application Pending form is not already present on your AR System, you
must stop and restart the AR System server before you can start using the
Approval Server.
E-2 Appendix E Troubleshooting

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

The URL for the Approval Web Approval Central is special. You should not open
your regular ARWeb login page to use the Approval Central form. Refer to your
AR System Administrator for the exact URL, but the default URL for a machine
named acme would appear as follows:
http://acme/esapps/approval/appstart.html
or
http://acme.remedy.com/esapps/approval/appstart.html
Browser Buttons Log Out User

Use only the Approval Web links and buttons to navigate within ARWeb. You can
log out of ARWeb unintentionally if you use the Back or Forward buttons of your
web browser.
Cannot Display Approval Web Pages

If your web server fails to display Approval Web pages, verify that the ARWeb
server /ARWeb/ENU directory has execute permissions.
Refer to Web Server Directory Permissions on page A-24 or your web server
documentation for a procedure to change server directory permissions.
Missing Tabs in Netscape

If you cannot see application tabs on Approval Central above the welcome screen,
click Reload button on your Netscape browser.
Sample Application Concerns
Sample Users
You must license the sample users to perform the procedures in Chapter 6, Using
a Sample Application.
Approval Web Concerns E-3

Miscellaneous Runtime Concerns
Approver Receives Request but Cannot Respond

There is likely a misspelled approver name in the Validate Approver rule. This
causes an approver to receive a request, but be unable to respond without
producing the error message: You are not currently defined as an alternate for
any user and you are not on the Approvers list for this approval (ARERR 10000).
Approval Server Wont Start Up With Oracle 8.0.x

Oracle 8.0.x starts up more slowly than the Approval Server, causing the
Approval Server to fail to start up properly. Installations with Oracle 8.0.x must
manually start the Approval Server service (Windows) or demon (UNIX) every
time you reboot, after Oracle is stable.
E-4 Appendix E Troubleshooting

F Installation Directory
Structures Appendix
This appendix lists the following directory information
Default Installation Directories
Directory Structure for Windows Installations
Directory Structure for UNIX Installations
F-1
Default Installation Directories
Without intervention, the Approval Server installs files into the following default
directory, depending on your platform.
Windows
C:\Program Files\Remedy\Approval
UNIX
/usr/ar/approval
Directory Structure for Windows Installations
Approval Server 4.x Files for Windows

AR_Server_Install_Dir (e.g. C:\Program Files\Remedy)
| arjoinfix.exe
| arapi45.dll
| arrpc45.dll
| arutl45.dll
| serverap.exe
|
+---Approval
| | AppImport.dbg
| | AppInst.dbg
| |
| +---debug
| |
| +---docs
| | approval.pdf
| |
| \---templates
| *.def
F-2 Appendix F Installation Directory Structures

| *.imp
| *.lst
| *.dat
| DemoLic.txt
| GenList.pl
| tmp
| tmp.out
|
+---Arserver
||
| +---DB
| | ar.lck.390609
| | arapprov.log
| |
| |
+---CONF
| ar.cfg
Approval Server 4.x Files for Windows F-3

Approval Web Files for Windows ARWeb 4.x
WEB_Server_Document_Dir (e.g. C:\NETSCAPE\SUITESPOT\DOCS)
+---ARWeb
| |
| +---ENU
| appdologout.jsp
| apploader.jsp
| arapi45.dll
| arrpc45.dll
| arutl45.dll
| autologin.jsp
| cgiapsup.exe
| server_APxAlternate_domodify.jsp
| server_APxAlternate_dosubmit.jsp
| server_APxAlternate_modifyfo.jsp
| server_APxAlternate_submitfo.jsp
| server_APxDetailxSignature_domodify.jsp
| server_APxMorexInformation_domodify.jsp
| server_APxMorexInformation_dosubmit.jsp
| server_APxMorexInformation_modifyfo.jsp
| server_APxMorexInformation_submitfo.jsp
| server_APxSample2xIssuexDetailxSignat_modifyfo.jsp
| server_APxSamplexLunchxDetailxSignatu_modifyfo.jsp
| server_APxSignature_domodify.jsp
| server_yourappname_modifyfo.jsp.template
| prelog.jsp
| prompt.jsp
|
|
+---esapps

| appswitcher.html
| blank.html
| gcheck.html
| logstart.html
|
+---approval
| | appalt.html
| | appaltin.html
| | appcheck.html
| | applist.html
| | applistin.html
| | applistin1.html
| | appquery.html
| | appstart.html
| | apquery.html
| | apquery1.html
| | apquery2.html
| | apsubmit.html
| | blank.html
| | blank1.html
| | blank3.html
| | check.html
| | checkcontrol.html
| | config.html
| | config.html.template
| | control.css
| | control.html
| | control1.css
| | diarydisplay.html
| | display.css
| | display1.css
Approval Web Files for Windows ARWeb 4.x F-5

| | incontrol.html
| | indata.html
| | licontrol.html
| | liquery.html
| | outframe.html
| | qcontrol.html
| | qcontrol1.html
| | qcontrol2.html
| | remban.html
| | subban.html
| | subbana.html
| | subbanb.html
| | subbanx.html
| | welcomeap.html
| |
| \---anim
| ap.gif
| appbut.gif
| approvals.gif
| approve.gif
| approveit.gif
| arslogo.gif
| arslogo1.gif
| arslogo2.gif
| asalt.gif
| bkg3.jpg
| blank.gif
| clearout.gif
| contbot.gif
| conttop.gif
| createmi.gif

| delout.gif
| details.gif
| gobut.gif
| help.gif
| home.gif
| homebut1.gif
| homebut2.gif
| info.gif
| midback.gif
| modify1.gif
| modify2.gif
| noaction.gif
| prmenu.gif
| reject.gif
| rejectit.gif
| rlogos.gif
| searchbut.gif
| seealt.gif
| submitdown.gif
| submitup.gif
| tabdown.gif
| tabup.gif
| viewinf.gif
| viewmi.gif
|
+---css
| default.css
| default.js
| win.css
|
+---Fcshelp

| actas.htm
| altinfo.htm
| appreq.htm
| approve.htm
| assaltapp.htm
| cnt0.gif
| cnt1.gif
| help.gif
| homebut1.gif
| index.gif
| index.htm
| index_a.gif
| index_b.gif
| index_c.gif
| index_d.gif
| index_e.gif
| index_f.gif
| index_g.gif
| index_h.gif
| index_i.gif
| index_j.gif
| index_k.gif
| index_l.gif
| index_m.gif
| index_n.gif
| index_o.gif
| index_p.gif
| index_q.gif
| index_r.gif
| index_s.gif
| index_t.gif

| index_u.gif
| index_v.gif
| index_w.gif
| index_x.gif
| index_y.gif
| index_z.gif
| listaltapp.htm
| listapp.htm
| login.htm
| logout.htm
| moreinfo.htm
| next0.gif
| next1.gif
| office1a.gif
| prev0.gif
| prev1.gif
| project.vpp
| styles.css
| supp1.htm
| viewmore.htm
\---images
| arslogo.gif
| blank.gif
| business.gif
| login.gif
| logout.gif
| office0a.gif
| pur.gif
| rlogos.gif
| rlogos1.gif
|

\---login
blank.gif
lg_01_01.jpg
lg_01_02.jpg
lg_01_03.jpg
lg_01_04.gif
lg_02_01.jpg
lg_02_02.gif
lg_02_03.gif
lg_03_01.gif
lg_03_02.gif
lg_04_01.gif
lg_04_02.gif
lg_04_03.gif

Approval Web Files for Windows ARWeb 3.x
Approval Web for ARWeb 3.x installs files in two locations: the web server
directory and the Remedy program files directory.
The Web Server Directory
Web_Server_Document_Dir (e.g. c:\netscape\suitespot\docs)
|
\---esapps
| logstart.html
| blank.html
| gcheck.html
| appswitcher.html
| home.html
|
+---approval
| | welcomeap.html
| | appaltin.html
| | applist.html
| | applistin.html
| | applistin1.html
| | appquery.html
| | apquery.html
| | apquery1.html
| | apquery2.html
| | apsubmit.html
| | blank.html
| | blank1.html
| | blank3.html
| | check.html
| | config.html

| | control.css
| | control.html
| | control1.css
| | display.css
| | display1.css
| | incontrol.html
| | indata.html
| | licontrol.html
| | liquery.html
| | outframe.html
| | qcontrol.html
| | qcontrol1.html
| | qcontrol2.html
| | remban.html
| | subban.html
| | subbana.html
| | subbanb.html
| | subbanx.html
| | appalt.html
| | appstart.html
| | appcheck.html
| |
| \---anim
| viewmi.gif
| appbut.gif
| approvals.gif
| approve.gif
| approveit.gif
| arslogo.gif
| arslogo1.gif

| arslogo2.gif
| asalt.gif
| bkg3.jpg
| blank.gif
| clearout.gif
| contbot.gif
| conttop.gif
| createmi.gif
| delout.gif
| details.gif
| gobut.gif
| help.gif
| home.gif
| homebut1.gif
| homebut2.gif
| info.gif
| midback.gif
| modify1.gif
| modify2.gif
| noaction.gif
| prmenu.gif
| reject.gif
| rejectit.gif
| rlogos.gif
| searchbut.gif
| seealt.gif
| submitdown.gif
| submitup.gif
| tabdown.gif
| tabup.gif
| viewinf.gif

| ap.gif
|
+---css
| win.css
| default.js
| default.css
|
+---Fcshelp
| wip.htm
| actas.htm
| addli.htm
| advanced.htm
| altinfo.htm
| appreq.htm
| approve.htm
| arrowl.gif
| assaltapp.htm
| chgqua.htm
| cnt0.gif
| cnt1.gif
| delli.htm
| eddet.htm
| editor.htm
| enter.htm
| fillin.htm
| help.gif
| homebut1.gif
| index.gif
| index.htm
| index_a.gif
| index_b.gif

| index_c.gif
| index_d.gif
| index_e.gif
| index_f.gif
| index_g.gif
| index_h.gif
| index_i.gif
| index_j.gif
| index_k.gif
| index_l.gif
| index_m.gif
| index_n.gif
| index_o.gif
| index_p.gif
| index_q.gif
| index_r.gif
| index_s.gif
| index_t.gif
| index_u.gif
| index_v.gif
| index_w.gif
| index_x.gif
| index_y.gif
| index_z.gif
| iteminfo.htm
| listaltapp.htm
| listapp.htm
| logfile.htm
| login.htm
| logout.htm
| modify.htm

| moreinfo.htm
| navigate.htm
| next0.gif
| next1.gif
| office1a.gif
| other.htm
| prefpart.htm
| prev0.gif
| prev1.gif
| price.htm
| prinfo.htm
| project.vpp
| receive.htm
| recvli.htm
| rejreq.htm
| relogin.htm
| reports.htm
| reptinfo.htm
| required.html
| review.htm
| send.htm
| start.htm
| statdef.htm
| styles.css
| submit.htm
| submit1.gif
| supp.htm
| supp1.htm
| tm.htm
| viewmore.htm
| webrepts.htm

| about.htm
|
\---images
| rlogos1.gif
| blank.gif
| business.gif
| login.gif
| logout.gif
| office0a.gif
| pur.gif
| rlogos.gif
| arslogo.gif
|
\---login
lg_04_03.gif
lg_01_01.jpg
lg_01_02.jpg
lg_01_03.jpg
lg_01_04.gif
lg_02_01.jpg
lg_02_02.gif
lg_02_03.gif
lg_03_01.gif
lg_03_02.gif
lg_04_01.gif
lg_04_02.gif
blank.gif

The Remedy Program Files Directory
AR Web 3.0 Install Dir (e.g. C:\Program Files\Remedy\ARWeb3.0)
|
+--forms
| zzz
| outerfm.for
| purgeid.for
| arweb.for
|
\---pepper
| schemas.for
| expirid.for
|
+---AP%3aAlternate
| submitfo.for
| dosubmit.for
| modifyfo.for
| domodify.for
|
+---AP%3aDetail-Signature
| domodify.for
|
+---AP%3aMore+Information
| submitfo.for
| dosubmit.for
| modifyfo.for
| domodify.for
|
+---AP%3aSignature
| domodify.for
|

+---AP-Sample%3aLunch-Detail-Signatu
| modifyfo.for
|
+---AP%3aIssue+Detail+Signat
+---logins
| prompt.for
| autologin.for
| dologout.for
| prelog.for
| apploader.for
|
\---AP-Sample2%3aIssue+Detail+Signat
modifyfo.for

Directory Structure for UNIX Installations
Approval Server 4.x Files for UNIX

AR_Server_Install_Dir (e.g. /usr/ar)
|
+---approval
| | AppImport.dbg
| | AppInst.dbg
| |
| +---bin
| | analyze
| | appsinst
| | ar_apuninstall
| | arapprov
| | arcopy
| | argetgroupname
| | arjanitor
| | arjoinfix
| | arservapd
| | driver
| | getgroup
| | verifyserverver
| |
| +---doc
| | |
| | \--pdf
| |approval.pdf
| |
| \---templates
| *.def

| *.imp
| *.lst
| *.dat
| DemoLic.txt
| GenList.pl
| tmp
| tmp.out
|
|--+
|----DB
ar.lck.390609
arapprov.log
Approval Server 4.x Files for UNIX F-21

Approval Web Files for UNIX ARWeb 4.x
WEB_Server_Document_Dir (e.g. /usr/netscape/suitespot/docs)
|
+---ARWeb
| |
| +---C
| appdologout.jsp
| apploader.jsp
| autologin.jsp
| cgiapsup
| server_APxAlternate_domodify.jsp
| server_APxAlternate_dosubmit.jsp
| server_APxAlternate_modifyfo.jsp
| server_APxAlternate_submitfo.jsp
| server_APxDetailxSignature_domodify.jsp
| server_APxMorexInformation_domodify.jsp
| server_APxMorexInformation_dosubmit.jsp
| server_APxMorexInformation_modifyfo.jsp
| server_APxMorexInformation_submitfo.jsp
| server_APxSample2xIssuexDetailxSignat_modifyfo.jsp
| server_APxSamplexLunchxDetailxSignatu_modifyfo.jsp
| server_APxSignature_domodify.jsp
| server_yourappname_modifyfo.jsp.template
| prelog.jsp
| prompt.jsp
|
|
+---esapps
| appswitcher.html
| blank.html

| gcheck.html
| logstart.html
|
+---approval
| | appalt.html
| | appaltin.html
| | appcheck.html
| | applist.html
| | applistin.html
| | applistin1.html
| | appquery.html
| | appstart.html
| | apquery.html
| | apquery1.html
| | apquery2.html
| | apsubmit.html
| | blank.html
| | blank1.html
| | blank3.html
| | check.html
| | config.html
| | control.css
| | control.html
| | control1.css
| | display.css
| | display1.css
| | incontrol.html
| | indata.html
Approval Web Files for UNIX ARWeb 4.x F-23

| | licontrol.html
| | liquery.html
| | outframe.html
| | qcontrol.html
| | qcontrol1.html
| | qcontrol2.html
| | remban.html
| | subban.html
| | subbana.html
| | subbanb.html
| | subbanx.html
| | welcomeap.html
| |
| \---anim
| ap.gif
| appbut.gif
| approvals.gif
| approve.gif
| approveit.gif
| arslogo.gif
| arslogo1.gif
| arslogo2.gif
| asalt.gif
| bkg3.jpg
| blank.gif
| clearout.gif
| contbot.gif
| conttop.gif
| createmi.gif
| delout.gif
| details.gif

| gobut.gif
| help.gif
| home.gif
| homebut1.gif
| homebut2.gif
| info.gif
| midback.gif
| modify1.gif
| modify2.gif
| noaction.gif
| prmenu.gif
| reject.gif
| rejectit.gif
| rlogos.gif
| searchbut.gif
| seealt.gif
| submitdown.gif
| submitup.gif
| tabdown.gif
| tabup.gif
| viewinf.gif
| viewmi.gif
|
+---css
| default.css
| default.js
| win.css
|
+---Fcshelp
| actas.htm
| altinfo.htm

| appreq.htm
| approve.htm
| arrowl.gif
| assaltapp.htm
| cnt0.gif
| cnt1.gif
| help.gif
| homebut1.gif
| index.gif
| index_a.gif
| index_b.gif
| index_c.gif
| index_d.gif
| index_e.gif
| index_f.gif
| index_g.gif
| index_h.gif
| index_i.gif
| index_j.gif
| index_k.gif
| index_l.gif
| index_m.gif
| index_n.gif
| index_o.gif
| index_p.gif
| index_q.gif
| index_r.gif
| index_s.gif
| index_t.gif
| index_u.gif
| index_v.gif

| index_w.gif
| index_x.gif
| index_y.gif
| index_z.gif
| listaltapp.htm
| listapp.htm
| login.htm
| logout.htm
| moreinfo.htm
| next0.gif
| next1.gif
| office1a.gif
| prev0.gif
| prev1.gif
| project.vpp
| styles.css
| supp1.htm
\---images
| arslogo.gif
| blank.gif
| business.gif
| login.gif
| logout.gif
| office0a.gif
| pur.gif
| rlogos.gif
| rlogos1.gif
|
\---login
blank.gif
lg_01_01.jpg

lg_01_02.jpg
lg_01_03.jpg
lg_01_04.gif
lg_02_01.jpg
lg_02_02.gif
lg_02_03.gif
lg_03_01.gif
lg_03_02.gif
lg_04_01.gif
lg_04_02.gif
lg_04_03.gif

Approval Web for UNIX ARWeb 3.x
Approval Web for ARWeb 3.x installs files in two locations: the webserver
directory and the Remedy program files directory.
The Web Server Directory
Web_Server_Document_Dir (e.g. /usr/netscape/suitespot/docs)
|
\---esapps
| logstart.html
| blank.html
| gcheck.html
| appswitcher.html
| home.html
|
+---approval
| | welcomeap.html
| | appaltin.html
| | applist.html
| | applistin.html
| | applistin1.html
| | appquery.html
| | apquery.html
| | apquery1.html
| | apquery2.html
| | apsubmit.html
| | blank.html
| | blank1.html
| | blank3.html
| | check.html
| | config.html
Approval Web for UNIX ARWeb 3.x F-29

| | control.css
| | control.html
| | control1.css
| | display.css
| | display1.css
| | incontrol.html
| | indata.html
| | licontrol.html
| | liquery.html
| | outframe.html
| | qcontrol.html
| | qcontrol1.html
| | qcontrol2.html
| | remban.html
| | subban.html
| | subbana.html
| | subbanb.html
| | subbanx.html
| | appalt.html
| | appstart.html
| | appcheck.html
| |
| \---anim
| viewmi.gif
| appbut.gif
| approvals.gif
| approve.gif
| approveit.gif
| arslogo.gif
| arslogo1.gif

| arslogo2.gif
| asalt.gif
| bkg3.jpg
| blank.gif
| clearout.gif
| contbot.gif
| conttop.gif
| createmi.gif
| delout.gif
| details.gif
| gobut.gif
| help.gif
| home.gif
| homebut1.gif
| homebut2.gif
| info.gif
| midback.gif
| modify1.gif
| modify2.gif
| noaction.gif
| prmenu.gif
| reject.gif
| rejectit.gif
| rlogos.gif
| searchbut.gif
| seealt.gif
| submitdown.gif
| submitup.gif
| tabdown.gif
| tabup.gif
| viewinf.gif

| ap.gif
|
+---css
| win.css
| default.js
| default.css
|
+---Fcshelp
| wip.htm
| actas.htm
| addli.htm
| advanced.htm
| altinfo.htm
| appreq.htm
| approve.htm
| arrowl.gif
| assaltapp.htm
| chgqua.htm
| cnt0.gif
| cnt1.gif
| delli.htm
| eddet.htm
| editor.htm
| enter.htm
| fillin.htm
| help.gif
| homebut1.gif
| index.gif
| index.htm
| index_a.gif
| index_b.gif

| index_c.gif
| index_d.gif
| index_e.gif
| index_f.gif
| index_g.gif
| index_h.gif
| index_i.gif
| index_j.gif
| index_k.gif
| index_l.gif
| index_m.gif
| index_n.gif
| index_o.gif
| index_p.gif
| index_q.gif
| index_r.gif
| index_s.gif
| index_t.gif
| index_u.gif
| index_v.gif
| index_w.gif
| index_x.gif
| index_y.gif
| index_z.gif
| iteminfo.htm
| listaltapp.htm
| listapp.htm
| logfile.htm
| login.htm
| logout.htm
| modify.htm

| moreinfo.htm
| navigate.htm
| next0.gif
| next1.gif
| office1a.gif
| other.htm
| prefpart.htm
| prev0.gif
| prev1.gif
| price.htm
| prinfo.htm
| project.vpp
| receive.htm
| recvli.htm
| rejreq.htm
| relogin.htm
| reports.htm
| reptinfo.htm
| required.html
| review.htm
| send.htm
| start.htm
| statdef.htm
| styles.css
| submit.htm
| submit1.gif
| supp.htm
| supp1.htm
| tm.htm
| viewmore.htm
| webrepts.htm

| about.htm
|
\---images
| rlogos1.gif
| blank.gif
| business.gif
| login.gif
| logout.gif
| office0a.gif
| pur.gif
| rlogos.gif
| arslogo.gif
|
\---login
lg_04_03.gif
lg_01_01.jpg
lg_01_02.jpg
lg_01_03.jpg
lg_01_04.gif
lg_02_01.jpg
lg_02_02.gif
lg_02_03.gif
lg_03_01.gif
lg_03_02.gif
lg_04_01.gif
lg_04_02.gif
blank.gif

The Remedy Directory. AR Web 3.0 Install Dir (e.g. /usr/
remedy/arweb3.0)
|
+--forms
| zzz
| outerfm.for
| purgeid.for
| arweb.for
|
\---pepper
| schemas.for
| expirid.for
|
+---AP%3aAlternate
| submitfo.for
| dosubmit.for
| modifyfo.for
| domodify.for
|
+---AP%3aDetail-Signature
| domodify.for
|
+---AP%3aMore+Information
| submitfo.for
| dosubmit.for
| modifyfo.for
| domodify.for
|
+---AP%3aSignature
| domodify.for
|

+---AP-Sample%3aLunch-Detail-Signatu
| modifyfo.for
|
+---AP%3aIssue+Detail+Signat
+---logins
| prompt.for
| autologin.for
| dologout.for
| prelog.for
| apploader.for
|
\---AP-Sample2%3aIssue+Detail+Signat
modifyfo.for

Glossary
administrator See AR System administrator, approval request A specific instance of an

process administrator. approval process for authorizing a particular AR
System application form.
Ad Hoc An approval process type with no
predictable routing, in which each approver Approval Server A module within the AR
selects the subsequent approver. System which routes forms to generate
See also: Parent child, level, Ad Hoc, and rule-based appropriate sign-off signatures. The Approval
Server also creates an audit trail for authorizing
process types.
AR System application forms.
alternate An AR System user with the
approved The status of a completed approval
authority to substitute for an approver within an
approval process. request when all approvers have responded
with agreement.
alternate approve An indication for
approver An AR System user with the
notifications when an alternate has responded
authority to sign for an approval process.
with an approval.
approver list The list of approvers eligible to
alternate reject An indication for notifications
when an alternate has responded by rejecting a respond on signature lines for an approval
process.
request.
AR System administrator An individual
application A group of forms (and associated
responsible for the management of the AR
workflow) that are collected by an administrator
and that are related to a particular business System, including setting up forms, setting
access rights for users, and designing the
function, for example, Employee Care or Help
workflow process.
Desk. An application is also a server object in
Remedy Administrator. Also an AR System form See also: process administrator.
that contains entries that need to be approved. AR System server The full set of AR System
approval process A procedure that generates software, including the AR System server
all necessary signatures for authorizing a processes and fast, list, and escalation server
particular AR System application form. processes. When installed on a workstation on
approval process done A rule type used to the network, the server software provides access
to the full feature set of the AR System and can
update the request when the approval process is
be accessed by UNIX workstations or 32-bit
done. These rules are used to indicate the result
of the approval process to the original request. Windows PCs on the network that are running
the AR System client software.
Glossary 1
auto approval A rule type that allows for default An AR System administrator- or user-
automatic approval of a request for any defined setting or value that automatically
submission that meets specified criteria. applies to a field if users do not supply a
different setting or value when submitting a new
button A field on a form that a user can click to
execute an active link. A bitmap can represent a request. See also administrator default, user
default.
button. See also menu item, toolbar button.
Detail pane The part of the main window that
cancel at later level An indication for
displays fields for entering data.
notifications when an approval process is
cancelled after it has been approved by a dialog box A set of fields that are displayed to
previous approver. users and must be responded to before they
continue to fill out a form. The administrator
cancelled The status of a completed approval
request which was withdrawn by the requester. creates a dialog box by using an active link
action.
chained approval process A sequence of
diary data type The data type used for fields
approval processes which appear to the user as
that enable you to capture a history of the
one approval, but in fact are made up of many
separate approval processes. actions taken for a request. The field stores
character data. It is an append-only field, and
close approve An indication for notification each addition is stamped with the time, date,
when a request has multiple possible approvers and name of the user who entered the item.
and another of the approvers approves the
request. done See approval process done.
closed The status of an approval request that error The status of an incomplete approval
request in which routing problems have
has been resolved and is no longer waiting for
occurred.
an approver or more information response.
field In the AR System, the main entity of a
close reject An indication for notification
when a request has multiple possible approvers form. All of the following are AR System fields:
data, table, page, active link control fields
and another of the approvers rejects the request.
(buttons, menu items, and toolbar buttons), and
completion rule A rule type that checks trim.
whether conditions exist to stop routing a
request. If a completion check is successful, then file menu A menu with items that are
retrieved from a file that contains a formatted
no new approvers will see the request. The
character menu.
request may not be done, but the request has
been routed to everyone who must respond. get authority A rule type that gathers
control pane The part of the browser window information about the current approver or
environment that is used by subsequent self
that displays the command buttons to process
approval or completion rule tests.
data.
control panel A form that is used as a
centralized entry point from which users choose
the business tasks they need to accomplish.
2 Glossary
get authority regular A rule type that gathers more information an approvers query for
information about the current approver or additional data that becomes part of the audit
environment that is used by subsequent trail of the approval request. The approver is not
completion rule tests. Note that these rules are required to delay the approval request until
not run before self approval tests. someone responds.
get authority self A rule type that gathers more info return An indication for
information about the current approver or notifications when a more information request
environment that is used by subsequent self has been responded to.
approval rule tests. Note that these rules are not new signature An indication for notifications
run before completion tests.
that a new signature record has been created
get next approver A rule type that finds the with an individual as an approver.
next approvers in the current process, including notification An alert that an AR System event
the first approver at the start of processing.
has occurred.
hold An indication for notifications when a
override approve An indication for
request is changed to the Hold status. This is
notifications when a process administrator has
also a status where an approval request is approved a request in a manner that
assigned to an approver but no Approval Server
circumvents the normal process.
activity occurs.
override reject An indication for notifications
join form A type of form that contains
when a process administrator has rejected a
information from two or more AR System forms. request in a manner that circumvents the normal
Although join forms function like regular AR
process.
System forms in most respects, they do not store
independent data. Join forms point to the data parent-child An approval process type with a
stored on the two AR System forms that were fixed relationship between approvers, such as
used to create the join form. found in a management hierarchy.
level An approval process type with no fixed See also: level, Ad Hoc, and rule-based process types.
relationship between the approvers, but rather pending The status of an incomplete approval
some relationship based on their membership in request that is waiting for response from an
some group. Often used with approval processes approver or more information.
requiring consensus from set of committees
permission The property setting that enables
where the individuals are related only by their
AR System administrators to control who can
membership on the committees.
view and change individual fields of a form.
See also: Parent child, Ad Hoc, and rule-based process Administrators also set permissions for forms
types. and active links. Permissions are defined for
menu item A command that is accessed from a each access control group. See also access
menu. control, group, user.
prep get next approver A rule type that
gathers information to be used by the get next
approver rules.
Glossary 3
process administrator An AR System user requester A user who submits a form that
who is a member of the Approval Admin group requires authorization, triggering the Approval
(402) and has authority to set up and maintain Server.
approval processes.
role A named alias for one or more approvers.
See also AR System administrator. Allows the definition of a position regardless of
reassign An action for an approver to reroute a the individual approvers who are currently
fulfilling that position.
request by changing the assigned approvers.
rule-based A custom approval process type set
reject by another approver An indication for
up by the process administrator. There are no
notifications when there are multiple required
assumptions about relationships between
approvals outstanding and one of the other
approvers. Everything is built into the rules.
approvers rejects the request.
See also: Parent child, level, and Ad Hoc process
reject by later level An indication for
notifications when an approval process is types.
rejected by an approver after it has been self approval A rule type that allows for
approved by a previous approver. automatic approval of a request if the submitter
of the request has sufficient authority for the
rejected The status of a completed approval
request when an approver has disagreed. request to be approved.
Remedy Administrator The AR System client signature record a database record for the
signature of an approver. If an approval request
tool used by AR System administrators and
requires more than one signature, then multiple
subadministrators to set up the system for use
by support staff and users. This includes setting signature records are generated for that single
approval request.
up forms, setting access permissions (users and
groups), and creating filters, escalations, active toolbar The row of buttons below the menu
links, menu lists, guides, and applications. bar that enables easy access to commonly used
Remedy Notifier The AR System client tool menu commands.
through which a notification can be sent to a toolbar button An icon for a menu item that
user. See also notification. triggers an active link. See also button, menu item.
Remedy User The AR System client tool in validate approver A rule type that is used to
which users enter and track requests through the verify that a name specified as the next approver
resolution process. Users can also search the is a valid user. Only used to verify a user
database, generate reports, and modify existing specified in an Ad Hoc process or an Ad Hoc
requests with Remedy User. override of another process type.
request A collection of information that
describes an event (transaction), such as a
problem or a service request.
See also: approval request.
4 Glossary
Index
A alternate approvers
accessing assigning 3-5, 4-7, 5-8
approval module forms 8-2 creating for others 4-10, 11-4
Approval Server 8-2 defined 2-4
Action Request filters 10-4 modifying information 4-9, 5-11
active links for Lunch Scheduler 13-8 reviewing information 4-9, 5-11
ad hoc serving as 3-5, 4-8, 5-9
approvers 7-10 alternate reject Glossary-1
defined Glossary-1 answering
defining processes 9-4 approval requests 4-2
process type vs. ad hoc override 7-10, 7-21 More Information requests 4-5, 5-7
sample application 6-2 AP:Admin-DeleteVerify dialog D-4
ad hoc process AP:Administration form 8-2, 12-4, D-3
described 7-21 AP:Admin-Rename dialog 8-4, D-5
Get Next Approver rules 10-13 AP:Admin-ServerSettings dialog 8-5, 8-8, D-6
adding AP:Alternate form 11-4, D-9
alternate approvers 4-10 AP:Detail form 7-3, 12-9, D-11
Manage More Information button 13-7 AP:Detail-Signature form 12-3, 12-7, D-12
Add-Sig command C-4 AP:Dtl-Sig-MoreInfoDialog dialog D-14
administrators AP:Form form D-15
defined Glossary-1 AP:More Information form 7-3, B-2, D-16
setting capabilities 8-6 AP:Notification form 8-11, B-3, D-17
administrators, process AP:Process Administrator form 8-6, 11-5, D-20
assigning capabilities 8-6 AP:Process Definition form 9-2, B-2, D-21
authority of 7-2 AP:Reserved Word form D-26
defined 7-2 AP:Role form 11-2, D-26
delegating authority 7-2 AP:Rule Definition form
Override Only 7-3 entering rule information 10-3
responsibilities of 7-2 field descriptions D-27
Specific Process 7-3 opening the form 10-2
All must sign field 10-14, 11-3 setting field values on forms 10-4
tabbed views 10-2
Index 1
AP:Signature form 7-3, D-30 Approval Process, types of
apjoinfix 12-4 ad hoc 10-13
Application Pending form A-2, C-2, E-2 level 7-19, 10-12
Application-Command process C-2 parent-child 7-17, 10-12
applications rule-based 7-22, 10-13
configuring for Approval Web 12-6 summary table 7-23
connecting to Approval Server 12-2 approval processes for Lunch Scheduler 13-3
defined Glossary-1 approval requests
Get Agreement 6-1 audit trails 7-3
Lunch Scheduler 13-1 defined Glossary-1
troubleshooting sample E-3 diagram of 7-5
Approval Central login list 5-3
form D-2 processing 3-2, 4-2, 5-2
hidden characteristic 12-2 reassigning 3-3, 4-6, 5-8
URL 5-2, E-3 responding to 4-2, 7-12
approval errors 3-4 sample application 6-1
approval module, accessing forms 8-2 specifying next approver 3-4, 4-6
approval notifications 7-24 status of 3-3
Approval Process viewing 3-2, 4-3, 5-4
ad hoc 7-21 approval routing, setting up 7-2
creating 7-2, 9-2 approval rules
defined 1-2 defined 7-4
deleting 9-10 deleting 10-33
diagram of 7-5, 7-16 modifying 10-33
done vs. complete 7-6 approval rules, types of
error handling 3-4 Approval Process Done 10-30
modifying 9-9 Auto-Approval 10-5
reassigning requests 3-3, 4-6, 5-8 Completion 10-28
requesting more information 3-3 Get Authority 7-8, 10-20
restarting 13-6 Get Authority Regular 10-23
specifying next approver 3-4, 4-6 Get Authority Self 7-8, 10-25
viewing approval request records 3-2 Get Next Approver 7-10, 10-12
Approval Process Done rules Prep Next Approver 10-10
creating 10-30 Self-Approval 7-8, 10-8
described 10-30 Validate Approver 7-10, 10-17
example of 10-32 Approval Server
Set Fields tab 10-31 accessing components 8-2
worksheet B-10 configuring 8-5
connecting applications to 12-2
2 Index
defined Glossary-1 AP:Detail-Signature D-12
incompatibility with bundled version AP:Form D-15
A-2, E-2 AP:More Information D-16
installing on UNIX A-19 AP:Notification D-17
installing on Windows NT A-4 AP:Process Administrator D-20
licensing before installation E-2 AP:Process Definition D-21
manually starting and stopping A-23 AP:Reserved Word D-26
moving applications to Approval Web 12-6 AP:Role D-26
Oracle 8.0.x and E-4 AP:Rule Definition D-27
previous installation E-2 AP:Signature D-30
URL 5-2 Approval Central D-2
Approval Server commands Business Time Holidays D-31
Add-Sig C-4 Business Time Workdays D-32
Det-Approved C-4 User D-33
Det-Cancelled C-5 Approval Web
Det-Error C-5 configuring applications for 12-6
Det-Rejected C-6 configuring without portmapper A-25
MoreInfo-Return C-6 hiding password fields 12-8
New-Details C-6 processing requests 5-2
Rename-Form C-7 requesting more information about
Rename-Process C-7 approvals 5-6
Sig-Approved C-7 responding to More Information requests 5-7
Sig-Cancelled C-8 reviewing requests 5-4
Sig-Notify C-8 showing password fields 12-8
Sig-Notify-Change C-8 troubleshooting E-3
Sig-Notify-State C-9 URL 5-2
Sig-Reassign C-9 viewing More Information requests 5-7
Sig-Rejected C-10 Approval Web, alternate approvers
Update-Config C-10 designating 5-8
Approval Server dialogs modifying 5-11
AP:Admin-DeleteVerify D-4 reassigning approval requests 5-8
AP:Admin-Rename D-5 reviewing 5-11
AP:Admin-ServerSettings 8-5, 8-8, D-6 serving as 5-9
AP:Dtl-Sig-MoreInfoDialog D-14 Approval Web, installation
Approval Server for the Web. See Approval Web notes on A-2
Approval Server forms UNIX A-22
AP:Administration D-3 Windows NT A-11
AP:Alternate D-9 Approval Workspace field 13-5
AP:Detail D-11 approval, defined 1-2
Index 3
Approve button 5-5 ARWeb
approvers configuration A-24
ad hoc 7-10 directory permissions A-24
approving requests 7-6 ARWeb 3.x
assigning alternate 3-5, 4-7, 5-8, 11-4 diary fields 12-9
completed vs. done requests 7-6 installing A-2
defined 2-3 required versions A-11
list of, defined Glossary-1 ARWeb. See Approval Web
modifying alternates 4-9, 5-11 Assigned To field 12-3
multiple 4-6 assigning
overriding 3-7, 4-10 administrator capabilities 8-6
problem with responses E-4 alternate approvers 3-5, 4-7, 5-8
rejecting requests 7-6 approval requests 4-6, 5-8
response in sample application 6-3 limited administration rights 7-2
reviewing alternates 4-9, 5-11 override capabilities 11-5
roles and 7-9 audit trail of approval requests 7-3
serving as alternate 3-5, 4-8, 5-9 authority
approving requests 6-3, 7-6, 7-12 process administrator and 7-2
appstart.html 12-6, 12-8 signature 4-8, 5-9
AP-Sample auto approval
LoadDiaryOnDisplay filter 12-9 checks 7-7
AP-Sample:Company form 13-3 defined Glossary-2
AP-Sample:Lunch Scheduler form 13-2, 13-7 Auto-Approval rules
AP-Sample:Lunch-Detail form 13-3 creating 10-5
AP-Sample:Lunch-Detail-Signatu form example of 10-7
13-3, 13-8 worksheet B-7
AP-Sample:Restaurant form 13-3
AP-Sample:Signature Authority form 13-3, 13-10
B
Business Time Holidays form
AR System administrator Glossary-1
configuring 8-17
AR System server Glossary-1
described D-31
AR System server, installation notes A-2
More Information escalations 9-8
ar.cfg C-10
Business Time Workdays form
ar.conf C-10
configuring 8-16
ar_apinstall A-19
described D-32
ar_apweb4install A-22
More Information escalations 9-8
ar_apwebinstall A-22
buttons
arstruct.h C-10
Approve 5-5
defined Glossary-2
Manage More Information 13-7
4 Index
Reject 5-5 Sig-Rejected C-10
Show Approval Summary 13-8 Update-Config C-10
Show Signature 13-8 complete vs. done 7-6
web browser 5-2, E-3 completing processes 7-6
Completion Checks
C diagram of 7-14, 7-16
cancel at later level Glossary-2
routing and 7-13
cancelled Glossary-2
rules 7-14
cancelling approval processes 13-6
Completion rules
category parameter C-2
creating 10-28
chained processes 7-15, 12-5, 13-5
described 10-28
Change Management A-2, E-2
example of 10-29
changing
worksheet B-10
alternate approvers 4-9
components, Approval Server 8-2
processes 9-9
config.html 12-6
rules 10-33
configuring
checks, auto approval 7-7
applications for Approval Web 12-6
checks, self approval 7-7
Approval Server 8-5
close approve Glossary-2
Approval Web without portmapper A-25
close reject Glossary-2
ARWeb A-24
closed Glossary-2
Business Time Holidays form 8-17
command format C-2
Business Time Workdays form 8-16
Command Pane 5-5
connecting applications to Approval Server 12-2
command parameter C-2
control pane Glossary-2
commands, Approval Server
control panel Glossary-2
Add-Sig C-4
Courier font xiv
Det-Approved C-4
Create Date field 12-3
Det-Cancelled C-5
creating
Det-Error C-5
actions for rules 10-4
Det-Rejected C-6
alternate approvers 4-10
MoreInfo-Return C-6
Approval Process 7-2
New-Details C-6
notifications 8-11
Rename-Form C-7
processes 7-4, 9-2
Rename-Process C-7
roles 11-2
Sig-Approved C-7
rules 10-2
Sig-Cancelled C-8
creating rules
Sig-Notify C-8
Approval Process Done 10-30
Sig-Notify-Change C-8
Auto-Approval 10-5
Sig-Notify-State C-9
Completion 10-28
Sig-Reassign C-9
Index 5
Get Authority 10-20 Det-Approved command C-4
Get Authority Regular 10-23 Det-Cancelled command C-5
Get Authority Self 10-25 Det-Error command C-5
Get Next Approver 10-13 Det-Rejected command C-6
Prep Next Approver 10-10 dialogs
Self-Approval 10-8 AP:Admin-DeleteVerify D-4
Validate Approver 10-18 AP:Admin-Rename 8-4, D-5
AP:Admin-ServerSettings 8-5, 8-8, D-6
D AP:Dtl-Sig-MoreInfoDialog D-14
daemon A-2, A-21
diary data type Glossary-2
debug mode C-10, D-6
Diary fields 12-9
debugging the Approval Server 8-5
diary.for.template file 12-9
default Glossary-2
directory permissions A-24
default directories F-2
directory structure F-2, F-20
defining
directory, web server permissions A-24, E-3
actions for rules 10-4
done vs. complete 7-6
alternate approvers 4-10, 11-4
Done, Process 7-6
notifications 8-11
roles 11-2 E
defining rules editing
Approval Process Done 10-30 alternate approvers 4-9, 5-11
Auto-Approval 10-5 processes 9-9
Completion 10-28 rules 10-33
Get Authority 10-20 enabling
Get Authority Regular 10-23 diary fields in ARWeb 3.x 12-9
Get Authority Self 10-25 notifications 8-8
Get Next Approver 10-13 Password field 12-8
Prep Next Approver 10-10 entering rule information 10-3
Self-Approval 10-8 errors
Validate Approver 10-18 approval 3-4
delegating authority 7-2 defined Glossary-2
deleting process 7-14
processes 9-10 escalations
rules 10-33 creating D-9
designating alternate approvers 3-5, 4-7, 5-8 enabling 8-8
designing processes B-2 More Information 9-7
Detail pane Glossary-2 signature 9-6, D-23
Detail records 7-3 signature worksheets B-3
Detail-Signature records 3-2 events that trigger notifications 8-12
6 Index
F AP:Detail-Signature 12-3, 12-7, D-12
feedback 1-4 AP:Form D-15
field Glossary-2 AP:More Information 7-3, B-2, D-16
field ID 1 12-2 AP:Notification 8-11, B-3, D-17
field ID 102 13-8 AP:Process Administrator 8-6, 11-5, D-20
field ID 13191 12-4 AP:Process Definition 9-2, B-2, D-21
field ID 536870920 13-5 AP:Reserved Word D-26
field ID 7 12-2, 12-3, 12-4 AP:Role 11-2, D-26
field ID 8 12-2 AP:Rule Definition 10-2, D-27
fields AP:Signature 7-3, D-30
All must sign 10-14, 11-3 Application Pending A-2, C-2, E-2
Approval Workspace 13-5 Approval Central D-2
Diary 12-9 Business Time Holidays 8-17, D-31
One must sign 10-14, 11-3 Business Time Workdays 8-16, D-32
Password 12-8 User D-33
Reassign 3-3, 4-6 forms, Lunch Scheduler
Request 12-2 AP-Sample:Company 13-3
Request ID 12-2 AP-Sample:Lunch Scheduler 13-2, 13-7
Status 4-2, 12-2, 12-4 AP-Sample:Lunch-Detail 13-3
file menu Glossary-2 AP-Sample:Lunch-Detail-Signatu 13-3, 13-8
filters AP-Sample:Restaurant 13-3
AP-Sample AP-Sample:Signature Authority 13-3, 13-10
LoadDiaryOnDisplay 12-9 installing A-8
AP-Sample:StartCostApproval 13-4
AP-Sample:StartLevelApproval 13-4
G
Get Agreement application
AP-Sample:StartOverdueApprov 13-4
ad hoc process 6-2
New-Details command 12-5
approving requests 6-3
specifying for rules 10-4
installing A-8
first approver list 10-13
licensing sample users 13-9
first level of approvers 10-13
parent-child hierarchy 13-10
flat file database A-2
reassigning requests 6-6
fonts xiv
requesting items 6-2
format of commands C-2
requesting more information 6-4, 6-6
forms
reviewing answers to More Information
AP:Administration 8-2, 12-4, D-3
requests 6-7
AP:Alternate 11-4, D-9
AP:Detail 7-3, 12-9, D-11
Index 7
Get Authority Regular rules H
creating 10-23 Hidden characteristic, Approval Central 12-2
defined Glossary-2 hold
described 7-14 defined Glossary-3
example of 10-24 response to requests 7-12
Set Fields tab 10-24
worksheet B-10
I
ID, reserved 12-2
Get Authority rules
IIS, Miscrosoft Internet Information Server A-24
creating 10-20
inner join 12-3
defined Glossary-2
installation notes A-2
described 7-8
installer script, UNIX A-20
example of 10-22
installing
Approval Server for UNIX A-19
worksheet B-8
Approval Server for Windows NT A-4
Get Authority Self rules
Approval Web for UNIX A-22
creating 10-25
Approval Web for Windows NT A-11
defined Glossary-3
Approval Web notes and A-2
described 7-8
AR System server notes and A-2
example of 10-27
licensing Approval Server E-2
worksheet B-7
troubleshooting E-2
Get Next Approver rules
ad-hoc process 10-13 J
creating 10-13 join forms
described 7-10, 10-12 applications with Approval Server 12-2
example of 10-16 defined Glossary-3
level process 10-12 join, inner 12-3
parent-child process 10-12
rule-based process 10-13 L
Set Fields tab 10-15 Last Modified By field 12-3
worksheet B-9 level
global approve D-12 approvers 10-13
global overrides 3-7, 4-11 defined Glossary-3
global reject D-12 identifier 10-13
group (402) Glossary-3 level process
described 7-19
Get Next Approver rules 10-12
8 Index
License Agreement A-6 modifying
licensing alternate approvers 4-9, 5-11
before Approval Server installation E-2 processes 9-9
sample users 13-9, E-3 rules 10-33
limiting administration rights 7-2 More Information
linking applications to Approval Server 12-2 defined Glossary-3
lists records D-16
first approver 10-13 worksheet B-2
signatures 13-7 More Information escalations
log file notifications 9-7
debugging and 8-5 setting parameters 9-8
Low Priority Notification worksheet B-5 worksheet B-2
Lunch Scheduler application More Information requests
approval processes 13-3 entering information 4-4, 5-6
chaining approval processes 13-5 responding to 4-5, 5-7, 7-12
forms 13-2 reviewing answers 4-5, 5-7
installing A-8 reviewing answers in sample 6-7
licensing sample users 13-9 using in sample application 6-4, 6-6
overview 13-2 MoreInfo-Return command C-6
parent-child hierarchy 13-10 multiple approvers 4-6
restarting approval processes 13-6
reviewing information 13-7
N
Netscape Enterprise Server A-24
showing password field 13-8
new signature Glossary-3
showing signatures 13-7
New-Details command 12-5, C-6
showing summaries 13-7
Next Approver rules 7-9
M Normal Priority Notification worksheet B-3
Major Account Level Approval approval notifications
process 13-4 creating D-8
Manage More Information button 13-7 defined Glossary-3
Management Cost Authorization approval enabling 8-8
process 13-4 escalation worksheets B-3
manually starting Approval Server A-24 examples of 7-24
manually stopping Approval Server A-24 methods 8-15
menu item Glossary-3 More Information escalations 9-7
Modifed Date field 12-3 process administrators and 8-7
modify.for.template file 12-7 setting up 8-10
Index 9
O Prep Get Next Approver rules
One must sign field 10-14, 11-3 described 7-10
Oracle 8.0.x E-4 example of 13-4
Other, Set Fields value 10-4 Prep Next Approver rules
Override Only Admin privileges D-20 creating 10-10
Override Only process administrators 7-3 worksheet B-9
override reject Glossary-3 previous Approval Server installation E-2
overrides, ad hoc 9-4 process administrators
overriding adding alternate approvers 4-10
approvers 3-7 assigning capabilities 8-6
assigning capabilities 11-5 authority of 7-2
global 3-7, 4-11 creating processes and rules 7-4
process administrators and 7-2 defined 7-2
single signatures 4-10 delegating authority 7-2
described 2-5
P Override Only 7-3
parameters C-2
overriding approvals 4-10
parent-child process
responsibilities of 7-2
described 7-17
Specific Process 7-3
Process definition worksheet B-2
sample applications and 13-10
Process Done rules 7-15
Password field 12-8, 13-8
Process, Set Fields value 10-4
passwords
processes
Approval Web and 12-8
chained 7-15
saving changes and 5-3
creating 9-2
setting up for users D-23
deleting 9-10
verifying D-13
designing worksheet B-2
pending Glossary-3
done vs. complete 7-6
performing overrides 3-7
errors 7-14
permissions
modifying 9-9
change 11-4
renaming 9-11
connecting applications and 12-2
restarting 13-6
defined Glossary-3
rules and 7-4
directory A-24
types of 7-17
web server directory A-24, E-3
processing approval requests 3-2, 4-2
portaloc string 12-6
Purchasing@Work A-2, E-2
portmapper A-25
portmapper and Approval Web A-25 Q
Query, Set Fields value 10-4
10 Index
R Rename-Process command C-7
reassigning repeat interval D-24
approval requests 3-3, 4-6 Request field 12-2
approval requests in Approval Web 5-8 Request ID field 12-2, 12-3
requests in sample application 6-6 request, defined Glossary-4
records requesters 2-2
Detail 7-3 requesting
Detail-Signature 3-2 items in sample application 6-2
Reject button 5-5 more information 3-3, 4-4, 5-6
reject response to requests 7-12 requests, approval
rejected Glossary-4 audit trails 7-3
rejecting defined Glossary-1
by another approver 7-6, Glossary-4 diagram of 7-5
by later level Glossary-4 login list 5-3
relationships processing 3-2, 4-2, 5-2
level approval process 7-19 reassigning 3-3, 4-6, 5-8
parent-child approval process 7-17 responding to 4-2, 7-12
roles and 7-9 sample application 6-1
Remedy Notifier 8-15 specifying next approver 3-4, 4-6
Remedy User status of 3-3
creating approval rules 10-1 viewing 3-2, 4-3, 5-4
modifying approval rules 10-1 requests, More Information
overriding approvers 4-10 described 3-3
processing approval requests 4-2 entering information 4-4, 5-6
reassigning approval requests 4-6 responding to 4-5, 5-7
requesting more information about reviewing answers 4-5, 5-7
approvals 4-4 reviewing answers in sample 6-7
responding to More Information requests 4-5 using in sample application 6-4, 6-6
reviewing answers to More Information reserved ID 12-2
requests 4-5 responding to
specifying next approver 4-6 approval requests 4-2
Remedy User, alternate approvers More Information requests 4-5, 5-7, 6-6
defining for other approvers 4-10 responses
designating 4-7 problem with E-4
modifying 4-9 types of 7-12
reviewing 4-9 responsibilities of process administrators 7-2
serving as 4-8 restarting processes 13-6
renaming a process 9-11 restoring forms during installation A-21
Rename-Form command C-7
Index 11
reviewing Completion B-10
alternate approvers 4-9, 5-11 Get Authority B-8
approval requests 5-4 Get Authority Regular B-10
Lunch Scheduler application and 13-7 Get Authority Self B-7
More Information responses 4-5, 5-7 Get Next Approver B-9
roles Prep Next Approver B-9
approver 7-9 Self-Approval B-8
creating 11-2 Validate Approver B-8
defined Glossary-4 Run Process action C-2
vs. relationships 7-9 runtime, troubleshooting E-4
routing, setting up for 7-2
RPC socket number D-6
S
sample Get Agreement application
rule-based process
ad hoc process 6-2
described 7-22
approving requests 6-3
example of 13-4
installing A-8
rules
More Information requests 6-4, 6-6, 6-7
approval process and 7-4
completion 7-14
reassigning requests 6-6
creating 10-2
requesting items 6-2
deleting 10-33
sample Lunch Scheduler application
modifying 10-33
approval processes 13-3
rules, types of
chaining approval processes 13-5
Approval Process Done 10-30
forms 13-2
Auto-Approval 10-5
installing A-8
Completion 10-28
Get Authority 7-8, 10-20
overview 13-2
Get Authority Regular 7-14, 10-23
Get Authority Self 7-8, 10-25
restarting approval processes 13-6
Get Next Approver 7-10, 10-12
reviewing information 13-7
Prep Get Next Approver 7-10
showing password field 13-8
Prep Next Approver 10-10
showing signatures 13-7
Process Done 7-15
showing summaries 13-7
Self Check 7-7
sample users, licensing 13-9, E-3
Self-Approval 7-8, 10-8
Self Check
Validate Approver 7-10, 10-17, E-4
approvals 7-5, 7-7
rules, worksheets for
rules 7-7
Approval Process Done B-10
Self-Approval
Auto-Approval B-7
defined Glossary-4
12 Index
overview 7-8 Prep Next Approver 10-10
Self-Approval rules Prep Next Approver worksheet B-9
creating 10-8 Self-Approval 10-8
described 10-7 Self-Approval worksheet B-8
example of 10-9 Validate Approver 10-18
worksheet B-8 Validate Approver worksheet B-8
server settings D-6 Setup@Work A-2, E-2
serving as alternate approver 3-5, 4-8, 5-9 Short Description field 12-3
Set Fields tab Show Approval Summary button 13-8
AP:Rule Definition form 10-4 Show Signature button 13-8
Approval Process Done rules 10-31 showpassword 12-8
assignment types 10-4 Sig-Approved command C-7
examples 10-5 Sig-Cancelled command C-8
Get Authority Regular rules 10-24 signature
Get Authority rules 10-21 authority 4-8, 5-9
Get Authority Self rules 10-26 escalations 9-6, D-23
Get Next Approver rules 10-15 escalations worksheets B-3
Validate Approver rules 10-19 line errors 3-4
setting up overriding single 4-10
alternate approvers 4-10 record Glossary-4
approval routing 7-2 signature-line records 10-12, 10-14
field values on forms 10-4 Sig-Notify command C-8
notifications 8-10 Sig-Notify-Change command C-8
roles 11-2 Sig-Notify-State command C-9
setting up rules Sig-Reassign command C-9
Approval Process Done 10-30 Sig-Rejected command C-10
Approval Process Done worksheet B-10 single signature overrides 4-10
Auto-Approval 10-5 socket number D-6
Auto-Approval worksheet B-7 Special Overdue Approval approval
Completion 10-28 process 13-4
Completion worksheet B-10 Specific Process process administrator 7-3
Get Authority 10-20 SQL, Set Fields value 10-4
Get Authority Regular 10-23 starting Approval Server manually A-23
Get Authority Regular worksheet B-10 starting the Approval Server E-4
Get Authority Self 10-25 status
Get Authority Self worksheet B-7 approval requests and 3-3
Get Authority worksheet B-8 Approval Status field 4-2
Get Next Approver 10-13 defining notifications 8-11
Get Next Approver worksheet B-9 Status field 4-2, 12-2, 12-3, 12-4
Index 13
Status field ID 7 12-2 Set Fields tab 10-19
stopping Approval Server manually A-23 worksheet B-8
Submitter field 12-3 viewing
alternate approvers 4-9, 5-11
T approval requests 3-2, 5-4
trails, audit, of approval requests 7-3
approvals 4-3
transfering requests 6-7
More Information responses 4-5, 5-7
tree, directory F-2, F-20
triggering notifications 8-8 W
troubleshooting web browser buttons 5-2, E-3
Application Pending form E-2 web document directory D-7
Approval Web E-3 web server A-24, E-3
approver cannot respond E-4 Windows NT
installation E-2 arjoinfix.exe 12-4
licensing E-2 default directories F-2
Oracle 8.0.x E-4 directory structure F-2, F-20
runtime E-4 installing Approval Server A-4
sample applications E-3 installing Approval Web A-11
manually starting Approval Server A-23
U manually stopping Approval Server A-23
uninstall A-28
starting the service A-23
UNIX
worksheets, process
arjoinfix 12-4
Low Priority Notification B-5
daemon A-2, A-21, A-24
More Information B-2
default directories F-2
Normal Priority Notification B-3
Process definition B-2
installing Approval Server A-19
Urgent Priority Notification B-4
installing Approval Web A-22
worksheets, rule
manually starting Approval Server A-24
Approval Process Done B-10
manually stopping Approval Server A-24
Auto-Approval B-7
Update-Config command C-10
Completion B-10
Urgent Priority Notification worksheet B-4
Get Authority B-8
URL, Approval Central 5-2, E-3
Get Authority Regular B-10
User form D-33
Get Authority Self B-7
V Get Next Approver B-9
Validate Approver rules Prep Next Approver B-9
approver cannot respond E-4 Self-Approval B-8
creating 10-18 Validate Approver B-8
described 7-10, 10-17 write licenses 13-9
example of 10-19
14 Index
Reader Response
Remedy Approval Server 4.0
Users Guide for Windows and UNIX
ARAS-400-UG-01 October 2000
Remedy Corporation welcomes your ideas about how to improve its documentation. Please take a moment to
answer the questions below. Explain any No responses in the Comments section, and include any other com-
ments you may have. Mail this page to the address printed on the reverse side (the address is on the next page if
you are using the PDF version of this guide), or fax it to (650) 903-9001 (U.S.). You can also send comments
through electronic mail to doc_feedback@remedy.com. (If you need product support, send electronic
mail to support@remedy.com, or log on to the support web site at
http://supportweb.remedy.com.)
Yes No
Does this manual contain all the information you expected?
Is all the information in this manual technically accurate?
Is this manual easy to read and understand?
Are there enough examples and illustrations?
Are the examples and illustrations accurate and helpful?
Comments:
Name: Title:
Company:
Address:
City: State: ZIP:
Phone number: Email address:
Place
Stamp
Here
Information Development
Remedy Corporation
1505 Salado Dr., Bldg. 2
Mountain View, CA 94043
USA
Fold Here

Rmdy Approval4

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Rmdy Approval4

Загружено:

Авторское право:

Доступные форматы

Remedy Approval Server 4.

1 Understanding the Approval Process

2 The Remedy Model for Approvals

Table of Contents iii

4 Processing Approval Requests with Remedy User

5 Processing Approval Requests with ARWeb

7 The Process Administrators Guide

8 Working with the Approval Server

10 Defining Approval Rules

11 Managing Users and Roles

12 Adding Approvals to Your Application

13 Implementing Sample Application Features

Table of Contents vii

A Installation and Configuration

viii Table of Contents

F Installation Directory Structures

Process Administrators who design and maintain approval processes.

Title Description Audience Format

Conventions Used in This Manual

bold Indicates a new or important term.

italic Indicates a reference to another manual.

courier Indicates computer output and names of various infrastructure

<italic_courier> Indicates a variable directory, file name, or string that users

bold courier Indicates data to be entered by the user.

Indicates a series of menu selections.

Used in the left margin to indicate a step-by-step procedure.

The Basic Approval

The Approval Process

The Remedy Approval Server

An approval is always a means to an end. A signature in the examples above

The Approval Process

1-2 Chapter 1 Understanding the Approval Process

Approval processes must be able to handle a variety of situations without failing.

The Remedy Approval Server

Common Experience Across Applications

The Remedy Approval Server 1-3

Notification plus Feedback

An alternative process could be a simple AR System notification. There is no

1-4 Chapter 1 Understanding the Approval Process

This chapter provides an overview of the Approval Serverfrom approach and

Key Concepts of the Approval Server

The Approval Process

Who Participates in the Approval Process

2-2 Chapter 2 The Remedy Model for Approvals

Individual Approver Versus Role

Who Participates in the Approval Process 2-3

2-4 Chapter 2 The Remedy Model for Approvals

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.

Who Participates in the Approval Process 2-5

More Information Requests

2-6 Chapter 2 The Remedy Model for Approvals

This chapter discusses the approval process as it pertains to approvers. It covers

Processing an Approval Request

Viewing Approval Requests

Performing Other Approval Actions

Handling Approval Errors

Designating Alternate Approvers

Chapter 4 and Chapter 5 cover procedures for acting on approvals.

Viewing Approval Requests

Figure 3-1 The Approval Central Form

3-2 Chapter 3 Working as an Approver