...

Example Use case

An employee end - user needs a new laptop. The user logs in and creates a new Purchase Request from the end user interface End User Interface (EUI). They specify who it's for, the type of purchase by Service Category, the business justification for the request, etc. Lastly they select the item(s) they are requesting via a Related Table to the Items Requested table, which in turn draws from the Items table. The user may also select from Assets in stock that matches the type of purchase they chose.

The end user's manager , receives an email that a new request needs approval. The manager can approve or reject directly from hotlinks in the email or edit the record manually from the power user interfacePower User Interface. As a supervisor, the manager changes the Supervisor Approved field to either Yes or No. A rule running on edits will then change the status to Supervisor Approved or Supervisor Rejected. If the request is approved, a notification will be sent to the Purchasing Team.

...

Upon creation, a rule sends emails to both the Requestor Requester the RequestorRequester's Supervisor , and the Purchasing Team notifying them of the new Purchase Request.

...

Once created, Purchase Requests follow a two-stage approval process. The creation emails sent to the RequestorRequester's Manager and the Purchasing Team lets them know that their approval is required and provides a link in the email to edit the record. A supervisor can edit the Supervisor Approved? field to yes or no, and the Purchasing Team edits the Procurement Group Approved field to yes or no. Rules validate these changes and move the Purchase Request to the appropriate status, such as Supervisor Approved when the supervisor changes the field to Yes.

...