Approval Server Won’t Start Up With Oracle 8.0.x . . . . . . . . . .E -4 F
Installation Directory Structures
Default Installation Directories ..
..
..
Windows...
...
...
...
...
...
..
...
..
...
...
UNIX..
...
...
...
...
...
..
...
..
...
...
...
..
..
..
..
..
..
..
..
.F -2 .F -2 .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 Administrator’s Guide” for a discussion of the Process Administrator’s 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 Guide
Overview of the AR System architecture and features with in-depth examples; information on other Remedy products
Everyone
Printand PDF
Action Request System Workflow Administrator’s Guide
Procedures for creating and modifying an AR System application for tracking data and processes
Administrators
Printa nd PDF
Action Request System Server
Server administration topics on configuring
Administrators
Printa nd
Administrator’s Guide
servers, optimizing performance, and maintaining the AR System; technical essays
PDF
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.
xiv
Preface
courier
Indicates computer output and names of various infrastructure components (such as files, directories, machines, and underlying data structures). Example: # Remedy AR System Daemons
Indicates a variable directory, file name, or string that users replace with the actual directory, file name, or string. Example:
bold courier
Indicates data to be entered by the user. Example: Type /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.
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.
The Approval Process An approval process is the set of rules and procedures for selecting people to review and authorize a request in the proper manner.
A process must have rules to 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 person’s 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 employee’s 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 srcinal 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 Today’s 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 Server —from 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.
The Approval Process An approval process is the set of rules and forms that generate data to authorize specific AR System workflow. An approval process consists of some definitions for the operation itself, rules that define what happens at each specific stage in the process, and a place to store signatures. These rules need to be understood by process administrators, but are transparent to approvers. The types of rules and how they interact are described under “Common Rules and Operations” on page 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 Frank’s company rules say he can get the signature of any manager to authorize reimbursement for office supplies. However, company rules say Frank must get his direct supervisor to authorize reimbursement for travel related expenses.
Jack, Larry, and Samantha have the role of manager, so any of them can approve Frank ’s office supplies.
Jack is the individual who supervises Frank, so only Jack can authorize Frank’s 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 y ou 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 as you. and An alternate someone whoof substitutes for you and acts with process your authority privilegesisfor a duration 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 person’s 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.
2-4
Chapter 2
The Remedy Model for Approvals
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 Samantha’s requests with Brigid’s 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 Samantha’s technical review requests and approves or rejects them with Samantha’s authority. Likewise, when Jack acts as Brigid, he has Brigid’s 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 Administrator’s Guide” for an explanation of the Process Administrator’s 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
2-6
Chapter 2
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.
The Remedy Model for Approvals
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
Processing an Approval Request 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 pa ge 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.
Performing Other Approval Actions 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
Requesting More Information 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 srcinal request. The srcinal 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 srcinal approval is independent from the More Information routing. Youor never to wait approval for the More Information answer. However, if you do approve rejecthave the srcinal 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.
Reassigning an Approval Request If you feel you are not the correct person to act on an approval request, many processes allow you to reassign a request to a different approver. In such cases, a Reassign field is displayed on the approval form. When you reassign an approval request, your obligation to act on it ends.
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.
Specifying the Next Approver 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.
Designating Alternate Approvers Alternate approvers are approvers, assigned either by you or by the Process Administrator, to serve in your place if you are unavailable. You can assign alternates for yourself, or you can be asked to serve as an alternate for another approver.
3-4
Chapter 3
Working as an 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 alter nate, 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 Violet’s requests. Jack cannot see Violet’s 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 srcinal 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 1–8. Jack designates Samantha as alternate for all his approval processes from August 1–5. However, from August 6–8 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 Jack’s alternate for Jack’s 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 Brigid’s alternate, he reviews requests only within processes where she has designated Larry as alternate. Acting as Brigid, Larry responds to Brigid’s 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.
3-6
Chapter 3
Working as an Approver
Performing Overrides Overrides can be thought of as a special power to correct unexpected situations. An override is performed by a process administrator instead of the normally defined approver, to move a request forward when the normal approver is not responding.
An override is useful for emergencies such as when an approver is absent or unable to respond, and no alternate approver is designated. The process administrator can override that signature line so the process can continue. 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 pr ocess 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 Ned’s 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
3-8
Chapter 3
Working as an Approver
4
Processing Approval Requests with Remedy User
Chapter
This chapter covers the following procedures for processing approvals with the Remedy User tool:
Processing an Approval Request Processing More Information Requests
Performing Other Approval Actions
Processing as an Alternate Approver
Additional Options for Process Administrators
Note For procedures using ARWeb, refer toChapter 5.
4-1
Processing an Approval Request 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
9.
List of Approval Requests
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 other’s More Information requests.
Requesting More Information 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 p age 4-2 for the procedure.
2.
Click Manage More Information. The More Information form appears.
Figure 4-3
3.
4-4
Chapter 4
More Information Request Form
In the To field, enter the name of the person from whom you want more information.
Processing Approval Requests with Remedy User
This can be the srcinal requester or any other person.
Warning This must be one person ’s 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
3.
the Question field. 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.
Performing Other Approval Actions 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
Reassigning an Approval Request Perform the following procedure if you must reassign an approval request. For conceptual information, see “Reassigning an Approval Request” on page 3-3. ➤ Reassigning an Approval Request 1.
Open the approval request. See “Processing an Approval Request” on p age 4-2 for 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.
Warning This must be one person ’s exact AR System login ID.
3.
Click Save.
Specifying the Next Approver With some processes, approvers can or must specify the next approver. For conceptual information, see “Specifying the Next Approver” on pa ge 3-4. Use the following procedure to specify the next approvers for a request. ➤
Specifying the Next Approver 1.
Open the approval request. See “Processing an Approval Request” on p age 4-2 for 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:
3.
4-6
Chapter 4
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.
Click Save.
Processing Approval Requests with Remedy User
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.
Designating Alternate Approvers Use the following procedure to create an alternate approver for yourself. If you want multiple alternates, repeat this procedure for each alternate. ➤ Designating an Alternate Approver 1. 2.
Log on to Remedy User. 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.
Warning This must be one person ’s exact AR System login ID.
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 srcinal 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
3.
4-8
Chapter 4
Alternate Identification
In the Current Approver field, enter the name of the person for whom you are acting as the alternate approver.
Processing Approval Requests with Remedy User
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.
Managing Alternate Approver Definitions 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 upperright 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.
3.
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.
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.
3.
Click Save to save your changes.
Performing Overrides If you have override capability for an approval process, you perform the same steps to approve or reject the request as the srcinal 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 1.
From the Application list of the Approval Central form, select the application for 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.
5.
4-10
Chapter 4
Click View Approvals.
Processing Approval Requests with Remedy User
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 P rocess Global overrides include approving or rejecting a request regardless of any response by normal approvers. 1.
From the Application list of the Approval Central form, select the application for 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.
4.
Click View Approvals. 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
4-12
Chapter 4
Processing Approval Requests with Remedy User
5
Processing Approval Requests with ARWeb
Chapter
This chapter covers the following procedures for processing approvals with ARWeb.
Processing an Approval Request Performing Other Approval Actions
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
Processing an Approval Request 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.
➤
Processing an Approval Request 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
2.
5-2
Chapter 5
Approval Central for Approval Web
Click Log In at the top right of the screen.
Processing Approval Requests with ARWeb
The Log In window appears. Log in to the Approval Server.
Figure 5-2
3.
Log In to the Approval Server
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.
Processing an Approval Request
5-3
➤
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
5-4
Chapter 5
Reviewing the Details of an Approval Request
Processing Approval Requests with ARWeb
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
2.
Command Pane While Viewing Request Details
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.
Processing an Approval Request
5-5
Performing Other Approval Actions 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.
Requesting More Information 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 Request” on page 5-4.
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.
5-6
Chapter 5
Processing Approval Requests with ARWeb
➤
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
3.
Displaying Your More Information Requests
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
Reassigning an Approval Request Perform the following procedure if you must reassign an approval request. For conceptual information, see “Reassigning an Approval Request” on page 3-3. ➤ Reassigning an Approval Request 1.
Open the Details of the approval request as shown in “Reviewing an Approval Request” on page 5-4.
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
3.
Reassigning an Approval Request
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.
Designating Alternate Approvers Use the following procedure to create an alternate approver for yourself. If you want multiple alternates, repeat this procedure for each alternate. ➤ Designating an Alternate Approver
5-8
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.
Chapter 5
Processing Approval Requests with ARWeb
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.
7.
Click Submit to save your changes.
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 srcinal 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 1.
Log in to ARWeb as shown in“Processing an Approval Request” on page 5-2.
Click GO to Act as an Alternate
Figure 5-11
2.
Acting as an Alternate
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
Figure 5-13
5-10
Chapter 5
Your Login ID
Identifying Your Current Signature Authority
Processing Approval Requests with ARWeb
Managing Alternate Approver Definitions Use the following procedure to review or modify information about an alternate approver. ➤
Viewing the Record for an Alternate Approver 1.
Log in to ARWeb as shown in“Processing an Approval Request” on page 5-2.
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
5-12
3.
Modify the fields you want to change.
4.
Click Submit to save your changes.
Chapter 5
Processing Approval Requests with ARWeb
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
6-2
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.
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 approver’s 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.
2.
Choose File → Open → All tab. 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.
6.
Click View Approvals. 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 Frank’s request no longer appears to Jack after he has approved it. ➤
Requesting More Information 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 William’s 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
4.
6-4
Chapter 6
More Information Dialog Box
Click Create a New.
Using a Sample Application
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, we’re 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 Violet’s response to the More Information request. In this event Larry ’s More Information request will be closed when Franks’ computer request is done, regardless whether the More Information request was seen by Violet.
Using a Sample Application
6-5
➤
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 William’s computer request, and Larry Goldstein’s 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 Violet’s More information requests.
4.
Open the Pending item from Larry Goldstein. The More Information form appears with the Response field enabled.
Figure 6-6
5.
Responding to a More Information Request
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 Frank’s srcinal 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.
➤Reassigning an Approval Request
6-6
Chapter 6
Note The ability t o reassign a request may not be available in all processes.
Using a Sample Application
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 William’s computer request. You must be logged in as Violet Anderson. 1.
Return to the Approval Central form.
2.
Select AP-Sample2:GetAgreement from the Application field menu list.
3.
Click View Approvals.
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
6.
Reassigning an Approval Request to Sue Smith
Click Save to make your changes permanent. Frank’s request is no longer available for Violet to approve or reject. Only Sue Smith and Larry can see Frank’s 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 Request” on page 6-5. This procedure requires that you followed the previous procedures to generate Frank William’s computer request through Violet’s More Information responses. 1.
Use Remedy User to log on as sample user Larry Goldstein.
1.
Open the Approval Central form.
2.
Select AP-Sample2:GetAgreement from the Application field menu list.
3.
Click View Approvals.
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.
Using a Sample Application
6-7
The Detail Signature form appears.
Figure 6-8
5.
Click Manage More Information button
Click the Manage More Information button. The More Information dialog box appears.
Figure 6-9
Larry’s 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 Violet’s response, Larry now has sufficient information to approve Frank’s 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 Frank’s computer request. ➤
Finishing the Sample Request These steps show you how to verify the status of a request after approval.
6-8
Chapter 6
Using a Sample Application
This procedure requires that you followed the previous procedures to generate Frank William’s 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.
4.
Choose File → Open → All tab. 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 Frank’s 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
Frank’s 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
6-10
Chapter 6
Using a Sample Application
7
The Process Administrator ’s 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 Administrator ’s 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 something—a birthday card for another employee, for example—you 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 Rulebased. 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 manager’s approval to be handled differently than the personnel department’s 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.
7-4
Chapter 7
The Process Administrator ’s Guide
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 Routing—Can I approve my own request?
Next Approver Rules - Determining Who Is Next—Who is the next approver?
Approver Response - The Signature Line—How did this approver react?
Routing Completion Check - Who’s Left?—Does this person’s approval complete the request? Process Done Rules—Is 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 Sue ’s request. However, Sue’s request is still active. Until Samantha and Ned have responded, the approval process for Sue’s purchase order is notdone.
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.
7-6
Chapter 7
The Process Administrator ’s Guide
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 company’s auto approval rule automatically approves Frank ’s 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 srcinal 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 approver’s 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 Frank’s 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.
7-8
Chapter 7
The Process Administrator ’s Guide
Approver Roles If the Self Check can’t 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 person’s 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. Frank’s actual manager Jack can approve the request, or any of Jack’s 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, Frank’s direct supervisor, is allowed to approve Frank ’s $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 S ystem 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 pa ge 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.
7-10
Chapter 7
The Process Administrator ’s Guide
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 P rocess 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 asksuser. for more information, the identifies approver the sends a morerequest information request to another The Approval Server approval 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 Ap proval Server processes the request against the Routing Completion Check, discussed in the next section.
7-12
Chapter 7
The Process Administrator ’s Guide
Routing Completion Check - Who ’s 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 - Who’s 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
7-14
Chapter 7
The Process Administrator ’s Guide
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 Frank’s $150 lunch request arrives at Jack’s 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 Jack’s manager Larry to approve Frank’s 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 srcinal 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.
7-16
Chapter 7
The Process Administrator ’s Guide
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 manageremployee 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 marketing approvers send the request to their marketing managers, and the engineering approvers send the request up the engineering chain of command. The important factor to notice is the hierarchical relationship between approvers. The Parent 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:
7-18
Chapter 7
The Process Administrator ’s Guide
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 srcinator of the approval request. This means that the “parent” of the approval request srcinator 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
Approval Process Types
7-19
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:
7-20
Chapter 7
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 ’s Guide
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.
Approval Process Types
7-21
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.
7-22
Chapter 7
The Process Administrator ’s Guide
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 Relationship Between Approvers?
How Is Next Approver Determined?
Approver Ad Hoc Overrides Available?
Parent Child
Yes. Fixed hierarchy. Used when routing up a management chain.
Get Next Approver rule determines relationship of next approver to current owner.
Optional.
Level
No fixed relationship between approvers. Used when routing between committees or departments.
Get Next Approver rule determines the level of next approver.
Optional.
Ad Hoc
No. All routing
No rule
Not applicable.
determined by the current approver.
determining the next approver.
Custom, as determined by the Process Administrator.
Custom, as determined by the Process Administrator.
Rule-based
Optional.
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 user’s default notification mechanism. Review these procedures for setting up approval notifications:
7-24
Chapter 7
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.
The Process Administrator ’s Guide
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
7-26
Chapter 7
The Process Administrator ’s Guide
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
8-2
Chapter 8
AP:Administration Form
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 won’t change names of attached rules. You must restore the process name manually and then rename the process to rename the attached rules.
6.
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 srcinal name in the From Old Name field, and in the To New Name field, type the one you have already manually changed.
8.
8-4
Chapter 8
Click Perform Rename to execute the rename action.
Working with the Approval Server
➤
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
2.
Approval Menu Server Settings
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
5.
A zero (0) in this field causes immediate implementation of a definition.
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.
➤
8-6
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.
Chapter 8
Working with the Approval Server
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.
5.
Override Only Admin—grants this user the ability to approve or reject a request regardless of the normal process.
Select one of the four following options from the Notify Method menu list.
6.
Full Admin—grants this user the ability to modify processes as well as the ability to approve or reject a request regardless of the normal process.
None—No message is sent. Notifier—Users are notified when they run Remedy Notifier. For more information about Remedy Notifier, see the AR System Server Administrator’s Guide. Email—Users 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 Default—Users 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.
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.
8-8
Chapter 8
Working with the Approval Server
3.
Click the Notifications tab.
Figure 8-5
4.
Defining Approval Events That Trigger Notifications
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:
8-10
Chapter 8
Notification Description—For basic descriptive information about the notification. Qualification—For selecting the event trigger and defining any additional conditional statement for triggering the notification. Notification Details—For notification parameters, such as the method of delivery, who receives the notification, and the text message. Administrative Information—For displaying assignment, help text, and change history.
Working with the Approval Server
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
2.
Define the Name of the Notification
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
6.
Determine the Event That Triggers the Notification
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
Notify On Event
8-12
Chapter 8
Notification Descriptions
Event That Triggers
Default Notify List
New Signature
When a new signature line is added to the approval request.
Approver list.
Approve
When the approval request is approved.
Approver list minus current approver.
Reject
When the approval request is rejected.
Approver list minus current approver.
Alternate Approve
When an alternate approves the approval request.
Individual Approved for.
Alternate Reject
When an alternate rejects the approval request.
Individual Approved for.
Override Approve
When a user with override capability approves the approval request.
Approver list.
Override Reject
When a user with override capability rejects the approval request.
Approver list.
Working with the Approval Server
Table 8-1
Notify On Event
Notification Descriptions
Event That Triggers
Default Notify List
Global Approve
When an administrator performs a global approve, terminating a process for a request.
Approver list.
Global Reject
When an administrator performs a global reject, terminating a process for a request.
Approver list.
Reassign
When an approval is reassigned to a different approver.
Approver list.
Error
When there is an error in the approval signature.
Individual who approved or rejected.
Cancel
When an approval request is cancelled.
Approver list.
More Info Return
When a request for more information is fulfilled.
Individual who requested more information.
Reject by Later Level
When the approval request is rejected after this signature has approved.
Approver list.
Cancel at Later Level
When the approval request is cancelled after this signature has approved.
Approver list.
Rejected by Another Approver
When the approval request is rejected by another signature record.
Approver list.
Hold
When an approval request is put on hold.
Approver list minus current approver.
More Info
When more information is requested by an approver.
Approver list minus current approver. Does not include requester.
Defining an Approval Notification
8-13
Table 8-1
Notify On Event
8-14
Chapter 8
Notification Descriptions
Event That Triggers
Default Notify List
Still Active
When an approval request is in an approval pending state and there has been no action.
Approver list.
Still Active Repeat
When a Still Active notification has been sent and there is still no action.
Approver list.
Still Pending
When an approval request is on hold in the approval cycle and there has been no action.
Approver list.
Still Pending Repeat
When a Still Pending notification has been sent and there is still no action.
Approver list.
Still Hold
When a Hold notification has been sent, but there is still no action.
Approver list.
Still More Info
When more information has been requested for a approval request and there has been no action.
Approver list.
Still More Info Repeat
When a Still More Info notification has been sent, but there is still no action.
Approver list.
Still Error
When an error in the approval cycle has occurred, but there has been no action to correct the error.
Approver list.
Still Error Repeat
When a Still Error notification has been sent, but there is still no action.
Approver list.
Change After Approve
When a change occurs that all past approvers should know about.
Approver list.
Working with the Approval Server
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
9.
Determine the Method and Content of the Notification
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.
Defining an Approval Notification
8-15
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.
1.
Configuring Business Time Workdays Log on to the appropriate AR server.
2.
Choose File → Create a New.
3.
Select Business Time Workdays and click OK.
➤
8-16
Chapter 8
Working with the Approval Server
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.
6.
Click Apply to save your changes.
➤
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
4.
Business Time Holidays Form
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.
6.
Click Apply to save your changes.
Where to Go Next Setting up Processes, Rules, and Roles are covered in separate chapters:
Chapter 9, “Defining an Approval Process”
Chapter 10, “Defining Approval Rules”
8-18
Chapter 8
Chapter 11, “Managing Users and Roles”
Working with the Approval Server
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 Definition—For basic information about the process, such as process name, application, type, and approval success criteria. Signature Escalations—For 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 Escalations—For scheduling notifications when an
approval request is in the More Information state. Administrative Information—For 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 pa ge 8-2 for the p rocedure.
2.
9-2
Chapter 9
Click the Process tab and click the Create button.
Defining an Approval Process
The AP:Process Definition form appears.
Figure 9-1
3.
AP:Process Definition Form, Process Definition Tab
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:
8.
No More Approvers
Use this value to indicate that the Approval Server should consider the approval process finished when all signature lines are complete. (A completion rule can also be used to end the process.)
Completion Rule
Use this value to indicate that the Approval Server should expect a Completion rule to determine the successful completion of the approval process. If you select this option, you must create a Completion rule and associate it with this process or the process will never complete.
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 Approver
Use this value to create a single signature line for one individual. If you specify multiple names the Approval Server returns an error.
9-4
Chapter 9
Defining an Approval Process
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 Approver Rules
To use a Get Next Approver rule to determine the first approver.
Assign To Owner If Approver
To use the requester as the first approver if the requester 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 Owner
To use the requester as the first approver in all cases.
Creating a Process
9-5
➤
Entering Signature Escalations on the P rocess 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.
9-6
Chapter 9
Defining an Approval Process
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.
Creating a Process
9-7
2.
Click the More Information Escalations tab of the AP:Process Definition form.
Figure 9-3
3.
More Information Escalations
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.
9-8
Chapter 9
Click Save to save your process.
Defining an Approval 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 1.
Open the AP:Administration form.
2.
See “Using the Approval Administration Interface” on page 8-2 for the procedure. 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 1.
Open the AP:Administration form. See “Using the Approval Administration Interface” on pa ge 8-2 for the p rocedure.
2.
Select the Process tab.
3.
Select the process you want to delete.
4.
Click Delete.
Figure 9-5
5.
Confirm Process Deletion
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.
9-10
Chapter 9
Defining an Approval Process
Renaming Processes ➤
Renaming a Process 1.
Open the AP:Administration form. See “Using the Approval Administration Interface” on page 8-2 for the procedure.
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.
9-12
Chapter 9
Defining an Approval Process
10
Defining Approval Rules
Chapter
This chapter describes how to use Remedy User to create and modify approval rules.
This chapter covers the following topics:
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 Rule Definition Form The AP:Rules Definition form consists of three tabbed views (depending on the type of rule):
Basic—For identifying information about the rule and, depending on the rule type, a qualification statement. Set Fields—For specifying the action to be executed by the rule if a transaction passes the qualification statement. Administrative Information—For reviewing assignment, help text, and change history.
The Rule Definition Form 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 1.
Open the AP:Administration form. See “Using the Approval Administration Interface” on pa ge 8-2 for the p rocedure.
2.
Click the Rule tab and click the Create button. The AP:Rule Definition form appears.
Figure 10-1
10-2
Chapter 10
New Rule Definition
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:
10-4
Chapter 10
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 Administrator’s Guide for more information on filters.
Defining Approval Rules
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 autoapproval 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 person’s authorization limit or job title. See “Working with Self-Approval Rules” on pa ge 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 Administrator’s 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.
10-6
9.
Click Save to save the basic information for the rule.
Note Auto-Approval rules do not use the Set Fields tab.
Chapter 10
Defining Approval Rules
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 SelfApproval rules can use values retrieved from another form. Self-Approval rules are generally designed to depend on a Get Authority Self or Get Authority rule to retrieve a value from another form. For example, a Get Authority Self rule can be designed to retrieve the signature authority level for the requester and write that value to a temporary field on the approval request. This makes the signature authority value available for use by a 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 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
3.
name field. 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. As soon as you select a rule type, the Rule Definition form changes to display the fields appropriate for the specific type of rule.
5.
Select a rule status from the Status field menu list. Select either Active or Inactive to indicate the status of the rule. While you are developing a set of rules for a process, it 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. You can type the condition 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 Administrator’s 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.
10-8
Chapter 10
Defining Approval Rules
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 pa ge 10-20 or “Working with Get Authority Self Rules” on pag e 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 1.
Open the Rule Definition form. See “The Rule Definition Form” on page 10-2 for the procedure.
Figure 10-6
2.
3.
New Prep Next Approver Rule
Enter a name for the rule (or update the existing name if necessary) in the 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. 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.
5.
Select a rule status from the Status field menu list. Select either Active or Inactive to indicate the status of the rule. While you are developing a set of rules for a process, it 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 Prep Next Approver rules.
7.
10-10
Chapter 10
Enter the rule condition in the Run If text box.
Defining Approval Rules
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 Administrator’s Guide. When the qualification is met, the rule actions execute. 8.
Click the Set Fields tab.
Figure 10-7
9.
Set Fields in Prep Next Approver Rule
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. 14. Click Save to save your changes.
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 types—level, 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 approver’s 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 srcinator 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
10-12
Chapter 10
Defining Approval Rules
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 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.
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.
5.
Select a rule status from the Status field menu list.
6.
Type an execution order number in the Order field.
7.
Select a value from the If Multiple Rows field menu list. The following choices are available:
8.
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.
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:
9.
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.
Clear
Leaves this field blank.
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.
10-14
Chapter 10
Defining Approval 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
Clear
created an approver list, that list is ignored. Leaves this field blank.
10. 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 Administrator’s 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 1.
Open the Rule Definition form. See “The Rule Definition Form” on page 10-2 for the procedure.
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. See “Using the Set Fields Tab on the Rule Definition Form” on page 10-4 for a description of the available choices.
4.
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.
Defining Basic Data for Get Next Approver Rules
10-15
5.
6.
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.
Enter a qualification statement to test for a valid approver.
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 person’s manager by locating a value in $Manager’s Name$ from the SHR:PeopleGroup
10-16
Chapter 10
Defining Approval Rules
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. See “The Rule Definition Form” on page 10-2 for the procedure.
2. 3.
Enter a name for the rule in the Rule Name field. 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. As soon as you select the rule type, the Rule Definition form changes to display the fields appropriate for a Validate Approver rule.
Qualification bar
Figure 10-9
Validate Approver Basic Tab
5.
Select a rule status from the Status field menu list.
6.
Enter an execution order number in the Order field.
7.
Enter the rule condition in the Run If text box.
8.
Click the Save toolbar button to save the basic information for the rule. To complete the Validate Approver rule, continue to the procedure for defining the Set Fields Data.
10-18
Chapter 10
Defining Approval Rules
➤
Defining the Set Fields Data for a Validate Approver Rule 1.
Open the Rule Definitions form. See “The Rule Definition Form” on page 10-2 for the procedure.
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. See “Using the Set Fields Tab on the Rule Definition Form” on page 10-4 for a description of the available choices.
4.
Select a form name in the From Form field. This value indicates where the rule should search for a matching approver name to validate the user entry.
5.
Select a value for the On Server field to indicate the form location.
6.
Enter a qualification statement to test for a valid approver.
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 Manager’s 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
➤ 1.
Open the Rule Definition form. See “The Rule Definition Form” on page 10-2 for the procedure.
10-20
2.
Enter a name for the rule (or update the existing name if necessary) in the 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.
Chapter 10
Defining Approval Rules
As soon as you select the rule type, the Rule Definition form changes to display the fields appropriate for a Get Authority rule.
Qualification bar
Figure 10-11
Get Authority Basic Tab
5.
Select a rule status from the Status field menu list.
6.
Enter an execution order number in the Order field.
7.
Enter the rule condition in the Run If text box, if applicable. “Example of a Get Authority Rule” on pag e 10-22 provides an example.
8.
Click the Save toolbar button to save the basic information for the rule. 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 1.
Open the Rule Definitions form. See “The Rule Definition Form” on page 10-2 for the procedure.
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. See “Using the Set Fields Tab on the Rule Definition Form” on page 10-4 for a description of the available choices.
4.
Select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP:Signature Authority form.
5.
Select a value from the On Server field menu list to indicate the form location.
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 approver’s 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 person’s 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
10-22
Chapter 10
Get Authority Rule Example
Defining Approval Rules
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 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.
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. As soon as you select a rule type, the Rule Definition form changes to display the appropriate fields for a Get Authority Regular rule.
Qualification bar
Figure 10-13
Get Authority Regular Basic Tab
5.
Select a rule status from the Status field menu list.
6.
Enter an execution order number in the Order field, if applicable.
7.
Enter the rule condition in the Run If text box, if applicable. You can type the condition statement or you can build it by using the qualification bar and list, as described in “Building Qualifications” in Chapter 10 of the Action Request System Workflow Administrator’s Guide. When the qualification is met, the rule actions execute. “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
8.
Click the Save toolbar button to save the basic information for the rule. 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 1.
Open the Rule Definitions form. See “The Rule Definition Form” on page 10-2 for the procedure.
2.
Click the Set Fields tab on the AP:Rules Definition form.
3.
Select a value from the Set Field Type field menu list. The Set Field Type indicates the type of assignment to be used for the rule action. See “Using the Set Fields Tab on the Rule Definition Form” on page 10-4 for a description of choices available.
4.
Select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP:Signature Authority form.
5.
Select a value from the On Server field menu list to indicate the form location.
6.
Enter a qualification statement to define the parameters for retrieving the authority data. For example, if you want to retrieve the current approver’s 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 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 person’s DollarSigningAmount field from the AP-Sample:Signature Authority form will be placed in a temporary field named TempReal 1.
10-24
Chapter 10
Defining Approval Rules
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. ➤ 1.
Defining the Basic Data for a Get Authority Self Rule 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.
3.
Select the associated approval request process from the For Process field menu list.
Working with Get Authority Self Rules
10-25
4.
Select Get Authority Self from the Rule Type field menu list. As soon as you select a rule type, the Rule Definition form changes to display the appropriate fields for the Get Authority Self rule.
Qualification bar
Figure 10-15
Get Authority Self Basic Tab
5.
Select a rule status from the Status field menu list.
6.
Enter an execution order number in the Order field, if applicable.
7.
Enter the rule condition in the Run If text box, if applicable. You can type the condition statement or you can build it by using the qualification bar and list, as described in “Building Qualifications” in Chapter 10 of the Action Request System Workflow Administrator’s Guide. When the qualification is met, the rule actions execute. “Example of a Get Authority Self Rule” on pag e 10-27 provides a look at a typical
8.
Get Authority Self rule. Click Save to save the 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 1.
Open the Rule Definitions form. See “The Rule Definition Form” on page 10-2 for the procedure.
2.
Click the Set Fields tab on the AP:Rules Definition form.
3.
Select a value from the Set Field Type field menu list. The Set Field Type indicates the type of assignment to be used for the rule action. See “Using the Set Fields Tab on the Rule Definition Form” on page 10-4 for a description of available choices.
10-26
Chapter 10
Defining Approval Rules
4.
Select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form.
5.
Select a value from the On Server field menu list to indicate the form location.
6.
Enter a qualification statement to define the parameters for retrieving the authority data. For example, if you want to retrieve the current approver’s 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 names of the fields to receive the data and the names of the fields where the data is located. You can use the field list button to the right of each of these fields to select the appropriate field names.
Example of a Get Authority 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 person’s 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 approver’s 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 individual’s or role’s 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 1.
Open the Rule Definition form. See “The Rule Definition Form” on page 10-2 for the procedure.
10-28
Chapter 10
Defining Approval Rules
2.
Enter a name for the rule (or update the existing name if necessary) in the Rule Name field.
3.
Select the associated approval request process from the For Process field menu list.
4.
Select Completion Rule from the Rule Type field menu list. As soon as you select a rule type, the Rule Definition form changes to display the fields appropriate for a Completion rule.
Qualification bar
Figure 10-17
Completion Rule
5.
Select a rule status from the Status field menu list.
6.
Enter an execution order number in the Order field, if applicable. Execution order applies to a set of Completion rules for a given process. If you are only defining a single Completion rule, the Order field may be left at zero.
7. 8.
Enter the rule condition in the Rule text box. Click the Save toolbar button to save the basic information for the rule.
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 1.
Open the Rule Definition form. See “The Rule Definition Form” on page 10-2 for the procedure.
10-30
Chapter 10
Defining Approval Rules
2.
Enter a name for the rule (or update the existing name if necessary) in the Rule Name field.
3.
Select the associated approval request process from the For Process field menu 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.
6.
Type an execution order number in the Order 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.
8.
Click Save to save the rule. 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 1.
Open the Rule Definitions form. See “The Rule Definition Form” on page 10-2 for the procedure.
2.
Click the Set Fields tab on the AP:Rules Definition form.
3.
Select a value from the Set Field Type menu list.
Defining Approval Process Done Rules
10-31
The Set Field Type indicates the type of assignment to be used for the rule action. See “Using the Set Fields Tab on the Rule Definition Form” on page 10-4 for a 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.
10-32
Chapter 10
Defining Approval 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
2.
Rule List
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.
4.
Click Save to save your changes.
Deleting Rules Follow these steps to delete an existing rule.
Note The delete operation is permanent and cannot be undone.
Be aware of any rule dependencies before deleting a rule. For example, SelfApproval and Completion rules 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.
10-34
Chapter 10
Defining Approval 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.
This chapter covers the following topics:
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
1.
AP:Role Form
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.
11-2
Chapter 11
Select an option from the If Multiple Approvers field menu list.
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
2.
Defining an alternate
Enter this alternate’s 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
4.
administrator or AR System administrator. 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 Process
Use this option to authorize a user as alternate for one specific process. The Process field becomes enabled so you can specify which process this alternate is authorized for. If this person is to be alternate for more than one process, you must create a separate alternate record to authorize each process.
5.
Type a date in the Start Date field. Type a valid date or select a date from the menu list.
6.
11-4
Chapter 11
Type an End Date.
Managing Users and Roles
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
6.
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.
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 Process
Use this option button to authorize a user as alternate for one specific process. The Process field becomes enabled so you can specify which process this alternate is authorized for. If this person is to be alternate for more than one process, you must create a separate alternate record to authorize each process.
8.
11-6
Chapter 11
Click the Save button to save the record.
Managing Users and Roles
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 application’s 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 ID
Default La be l
Permissions
Allow Any User to Submit
Default Value
1
RequestID
Assignee(view)
No
No
Yes
$\USER$
No
-
Yes
$\USER$
Public (view) 2
Submitter
Assignee(view)
3
Create Date
Assignee (view)
Public (view) Public (view) 4
Assigned To
Assignee (change) Public (view)
5
Last Modified By
Assignee(view)
No
-
6
Modified Date
Assignee(view)
No
-
7
Status
Assignee(write)
Yes
New
Yes
-
Public (view) Submitter (write) 8
Short Description
Assignee (write) 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:DetailSignature form. Display only those fields that are significant or that you want your users to have access to.
e.
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.
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.
12-4
Chapter 12
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 application’s 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).
Adding Approvals to Your Application
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 NewDetails 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: /esapps/approval
a.
Copy the contents of config.html.template into your config.html file. Paste the contents immediately in front of the 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.
2.
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.
Use a text editor, such as Wordpad, to open the file appstart.html located in this directory: /esapps/approval
12-6
Chapter 12
Adding Approvals to Your Application
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\\
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, “”
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.
/esapps/approval
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.
12-8
Chapter 12
Adding Approvals to Your Application
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 is for users of ARWeb version The following steps describe how procedure to allow approvers to view existing Diary3.x. 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:
