This documentation supports the 21.05 version of Action Request System.
To view an earlier version, select the version from the Product version menu.

Using the Lunch Scheduler sample application

The Lunch Scheduler is a sample application deployed with  Approval Server  ( Approval Server ). This application gathers approvals for employees of an imaginary company to schedule lunches with customer accounts. It uses three processes, each a different type, to implement the business rules of the company. Each process uses various types of rules.

The Lunch Scheduler and Get Agreement sample applications are not actually packaged as  AR System  applications. They consist of a related set of workflow objects, including the approval request form, active links and filters, approval processes, and approval rules. For information about the rules used in each process, see Defining approval rules.

When using Lunch Scheduler, the requester specifies information about the customer, the restaurant, and the number of attendees. These choices populate fields containing details about the total costs and information about the customer's relationship with the company.

Lunch Scheduler approval request form 

Lunch Scheduler includes three different approval processes chained together and uses three different filters with Run Process commands to start these processes. (For more information, see Using Run Process and $PROCESS$ commands.) The chained processes are:

  • Management Cost Authorization—This is a managerial approval based on the total cost of the lunch. It is a Parent-Child process, so the request is routed to a hierarchical series of managers until a manager with sufficient cost authority approves it. The filter AP-Sample:Start Cost Approval starts this process.
  • Major Account Level Approval—This process runs if the account is a major or enterprise account. It is a Level process that causes the request to be routed to the major account and enterprise account teams. The filter AP-Sample:Start Level Approval starts this process.
  • Special Overdue Approval—This process implements a special review of the request if the account is currently overdue. It is a Rule-Based process. The filter AP-Sample:Start Overdue Approv starts this process.

When requests are submitted in this application, they follow the appropriate approval processes. The processes enforce the business rules of the company, and the approval data gathered provides an auditable record of the business lunch activity at the company.

The Questions, Comments with attachments, Notes, and Multi-process preview features are available out-of-the-box with this sample application. For more information, see Form to view history of activities on a request for an approval process

The main forms associated with the Lunch Scheduler application are:

  • AP-Sample:Lunch Scheduler—This is the approval request form for the application.
  • AP-Sample:Lunch-Detail—This is the inner join between the AP-Sample:Lunch Scheduler and AP:Detail forms. It is used for internal processing by the Approval Server  and for Global Override operations. The join criteria is Request ID to Request.
  • AP-Sample:Lunch-Detail-Signatu—This is the three-way inner join between the AP-Sample:Lunch Scheduler and AP:Detail-Signature forms. This is the detail form that is available to approvers when they choose to view a request in Approval Central. The join criteria is Request ID to Request.
  • AP-Sample:Company—This is a supporting form that stores data about customer accounts. This data supports menus, workflow, and queries about the customer companies in the application.
  • AP-Sample:Restaurant—This is a supporting form that stores data about restaurants. This data supports menus, workflow, and queries about the restaurants in the application.
  • AP-Sample:Signature Authority—This is a supporting form that stores data about approvers. The Approval Server  uses this data from this form to identify hierarchical relationships in the organization. This data supplies information about the account teams and is used to identify next approvers in the Parent-Child and Level processes. The application's rules and processes use information from this form about approvers' signature authority to determine routing and whether the process is done.
Was this page helpful? Yes No Submitting... Thank you