Managing Requests (Workflow)

"Managing requests" is a phrase primarily aimed at gated requests, and means shepherding a request along a workflow from creation to approval. Often a request takes an uninterrupted path and its trajectory is straight. However, requests can be paused, sent back to a gate already visited, can skip a gate entirely, or be rejected outright.

It's a good idea to understand the moving parts that impact the journey of a request, including the people with permission to take action on a request (the players), the actions themselves, and the request statuses that update in response to the actions.

Status and Gate Status Fields

There are two "status" fields that can be used with requests: Status and Gate Status.

The Gate Status field is provided by PPM Pro and is part of the workflow - it applies only if you are using gates. Gate Status reflects the request's status as it moves through the workflow: New, In Progress, Approved, Rejected, On Hold. See Request Statuses. If you are using the card view, Gate Status and Current Gate can be used as the Group By field (each lane representing a gate).
The simple Status lookup list is provided by PPM Pro and can be placed on a request Details tab if so desired. You can add/remove/edit list values for this simple Status and also take advantage of Implied Status. If there are no gates configured for a request, then the simple Status field can be used on the request Details, and the Gate Status field is not required. If you are using the card view, standard lookup lists such as Status can be used as the Group By field. It is usually not recommended to use the general Status list along with the Gate Status list when a request category has gates, as having two status lists might confuse users; if you need to use the Status field besides Gate Status, consider meaningfully renaming one or both of these in Admin.

Save vs Submit

When working with requests, it is often useful to be able to save the request without having to move it on to the next gate. You can save a request that you are working on provided that the fields marked with a single red asterisk (*) contain valid values. Once the values are there, the Save button will be active. You can continue to work on the request until you are ready to submit it.

In order to submit (or approve) a request, the fields marked with two red asterisks (**) must contain valid values. Once the values are there, the Submit button will be active.

The Players

There are three major players in the request world: creator, requester, and approver. Those users get implicit permissions to act on a request. Other users can be given explicit (profile-based) permissions (Approve/Reject/Send Back to Prior Gate, Put on Hold/Put Back in Progress) to simulate their capabilities. The request actions that are available depend on the current user's permissions - implicit or explicit - and where the request is in the workflow. Each player is described below:

Creator - User who physically creates the request (often same user as the requester). The request Created By field is automatically populated as the user who clicked the New button. Creators have implicit rights to view, edit, delete, and submit the request(s) they create, as well as place on hold/place back in progress.
Requester - User who wants the request created and submitted. The Requester field is populated automatically with the value of the request Creator, but its value can be changed by the Creator in support of the scenario where the request is being created on behalf of someone else. Requesters have implicit rights to view, edit, submit, and delete their request(s), as well as place on hold/place back in progress, regardless of whether they physically created the request (provided they are a PPM Pro user).
Approver - (Gated requests only, post-submission) User who is configured (derived as a result of approval logic, or explicitly with Approve profile permission) as an approver for a specific gate. Approvers have implicit permission to execute all request actions: Approve/Reject/Send to Prior Gate, Put on Hold/Put Back in Progress (provided the request category supports all actions).
User with explicit Approve/Reject/Send to Prior Gate permissions - (Gated requests only, post-submission) Can perform these actions globally, or on specific request categories (and provided the request category is configured with "Allow request to be sent back to any gate" in support of the Send To Prior Gate action).
User with explicit Put on Hold/Put Back in Progress permissions - (Gated requests only, post-submission) Can perform these actions globally, or on specific request categories.

Request Statuses

(Applies to gated requests only) The set of request statuses inform where the request is in the workflow and are displayed in the Gate Status field. The current gate status determines the actions available on a request. When you take action on a request, the request status usually changes. The statuses are defined below; the interaction between statuses and actions is in the Request Actions section.

New - The request is created and saved, but not yet submitted. Fields that are configured to Show on New appear here; users with appropriate permissions can view/edit. You can change a request category while a request has a status of New.
In Progress - The request is submitted and at a gate, or has been fully approved at a gate and is at the next gate. Users with appropriate permissions can view/edit an In Progress request.
Approved - The request has been approved at all relevant gates and is no longer in progress. Finally-approved requests cannot be edited, however you can still copy attachments and notes into associated entities. Further, permitted users can create new entities (automatically associated) or add associations to existing entities - associations cannot be deleted from finally-approved requests. Note that when a request is approved it will display all fields that appeared on the request form, regardless of where they were configured to be shown (including fields shown on New). Field access restrictions are honored.
Rejected - The request has been taken out of the workflow, is no longer in progress, and cannot be put back in progress or edited, however you can still copy attachments and notes into associated entities. If you wish to re-establish a rejected request, first make a copy of the request and then resubmit it. Note that when a request is rejected it will display all fields that appeared on the request form, regardless of where they were configured to be shown. Rejected requests cannot be edited. Field access restrictions are honored.
On Hold - The request has been taken out of the workflow but can be placed back in progress. Users with appropriate permissions can view/edit/delete a request that is On Hold (should be same as those who can edit the request in the New state). Note that when a request is on hold, it will display only those fields configured to "Show on New". When put Back in Progress, request is sent to same gate as when put on hold. You can change a request category while a request is on Hold; if the gate no longer exists, the request will be placed back at the first gate when put Back in Progress.

Note that if you are using the Card view and grouping by Gate Status, you cannot drag cards to different swim lanes. Because each lane represents a gate status, you must take the appropriate workflow action (such as Approve, Reject, Send Back to Prior Gate) to move to another gate.

Request Actions

There is a set of general actions and buttons that are gate-agnostic - that is, they are available whether the request is gated or gate-less, and they are available for all players (requester/creator, approver). For gated requests, there is an additional set of workflow actions plus Submit/Approve buttons, as well as an "Other Actions" menu. The Other Actions options are also available from the right-click context menu.

General actions - Save/Cancel/Copy URL and Actions menu (gated and gateless requests)

Save -
- For gateless requests, saves the form (all fields marked with an asterisk (*) must have values). This is the only action for gateless requests.
- For gated requests, allows the request to be saved prior to submission or approval provided fields marked with a single asterisk (*) have valid values. Fields marked with two asterisks (**) can be empty during save, but must have valid values prior to submission or approval. This allows you to save the request if you are not ready to submit or approve it.
Save & Submit, Save & Approve (gated requests only) - Allows the request to be saved and submitted, or saved and approved at the same time.
Cancel - Discards any values you have entered.
Copy URL - Copies the URL of the request form to the clipboard.
Actions menu
- History - Displays a list of all fields that have been modified. Includes name of field, last modified by and last modified date, old/new values.
- Layout - Displays list of column layout options to format the request form.
- Print - Displays a page from which you can print the request or copy the request fields to the clipboard.

Workflow Actions - Submit + "Other Actions" menu (menu appears after request is submitted)

Submit - Click this button to enter the request into the workflow (puts request status 'in progress'). Available for gated requests only after all required fields have valid values, including fields marked with two asterisks (**). Once you submit a request, its status is In Progress and usually is delivered to the first gate - what happens next depends on whether you are using sequential gate flow or gate skipping. The Submit button is visible to requesters and creators and users with explicit Request > Submit permission will see this button. If the request category has been configured with the alert "Send notification to requester upon submission", then an alert will be sent to the requester upon submission when the submitter is not the same person as the requester. If the gate itself has been configured with the alert "Upon entering this gate, send email notification to all relevant gate approvers", then an alert will be sent to the relevant approvers of the first gate.
Approve - Sends the request to the "next gate" - if using gate skipping it might not be the next sequential gate. If there is another gate to go through (sequential or not), the request status is In Progress. If this is the last approval for all relevant gates, the status is Approved and the request is removed from the workflow. The Approve button is visible to implicit approver(s) for the request, and users with explicit Approve permission. If the gate itself has been configured with the alert "Upon entering this gate, send email notification to all relevant gate approvers", then an alert will be sent to the relevant approvers (unless there are no more gates to go through, in which case it does not move to another gate).
Send Back to Prior Gate - Places the request in a gate (selected by the user) that the request has already gone through before the current gate. The user can only choose a gate that had initially been visited (no skipped gates). Note that this action is available only for requests whose category is configured with "Allow request to be sent back to any gate". If the prior gate itself has been configured with the alert "Upon entering this gate, send email notification to all relevant gate approvers", then an alert will be sent to the relevant approvers (even though the request is moving backwards, it is entering a gate). Once the request has been sent back to a prior gate, any previously skipped gates can be visited, if the gate logic dictates.
Place on Hold - Removes the request from the workflow. Requester/creator can edit/delete request while on hold. Note when you Place Back in Progress all existing approvals for the gate will be wiped out. Approvers will need to re-approve the request, even if they approved prior to putting the request on hold.
Place Back in Progress - Puts the request back into the workflow at the gate it was at when placed On Hold - for both sequential and gate skipping flows - and any existing approvals will be wiped out. The configured gate entry notification will be sent because the request is effectively restarting at that gate.
Reject - Removes the request from the workflow permanently. If you wish to resubmit the request, you must first make a copy of the rejected request and re-enter it into the workflow (make appropriate changes and then Submit). Note that when the request is rejected it is immediately taken out of the workflow, even if there are multiple pending approvers.

Placing a Request on Hold

Users with the appropriate implicit or explicit permissions can place a request on hold by choosing Other Actions > Place on Hold. Users with appropriate permissions can view/edit/delete a request while it is on hold, including the requester/creator, who has implicit permission to edit/delete the request when it's on hold. When you place a request on hold you will be prompted with the following dialog:

You can enter an optional note, which will be stored in the Activity Log tab. You can check "Notify other pending approvers" to automatically send an alert other approvers (who have not yet approved) that the request has been put on hold. Check "Notify requester" to automatically send an alert to the requester (provided the requester is a user). The On Hold Note will be included automatically in email notifications to other pending approvers and the requester.

To reinsert the request back into the workflow, choose Other Actions > Place Back in Progress. You will be prompted with a similar modal, where you can optionally enter a note and choose to notify the requester that the request is being put back in progress. Any existing approvals will be wiped out and the pending approvers list will be refreshed. If you already approved the request and are still a pending approver, you will need to approve the request again.

Tip: A common scenario while a request is in flight is the need to get additional information from the requester/creator. To do this, use the Place Request On Hold action to remove the request from the workflow - be sure to use the Notify Requester notification to ask requester for what you need with the On Hold Note. The requester can edit the request while it is on hold to supply/update the information, and then Place Request Back In Progress. The request will re-enter the workflow at the gate it was at when it was put on hold. Any approvals that happened before the request was put on hold will be wiped out.

Notifications

There are several notifications around gated requests: some are provided category-wide (apply to all gates), and some are gate-specific. The potential notifications are described here, and every customer will implement as they see fit. If you want to turn on/off a notification, contact your PPM Pro administrator.

Send notification to requester upon submission

Your PPM Pro administrator sets this at the category level, meaning this notification will be used by any request using a category where this alert is configured. When configured, the system sends an alert to the requester each time the request is submitted, provided the submitter is not the same person as the requester.

Upon entering this gate, send email notification to all relevant gate approvers

Your PPM Pro administrator sets this alert per gate - it sends an alert to all relevant gate approvers when the request enters a gate configured with this alert. Note this alert will fire when a request is sent back to a prior gate that is configured with this alert.

Send reminder email to approvers who have not yet approved

This alert is set per gate and sends a reminder to any relevant gate approvers who have not yet approved the request.

Notify requester and other pending approvers

As mentioned above, when you place a request on hold, place back in progress, approve, reject, or send it back to a prior gate, you have the option of sending a notification to the requester which automatically includes the entered Note. You also notify other pending approvers. For Approve, Reject, and placing a request on Hold, "other pending approvers" are all approvers at the current gate who have not yet approved the request. For placing a request Back in Progress, "other pending approvers" are all approvers at the gate the request is returning to, because any prior approvals have been removed. For sending a request Back to a Prior Gate, "other pending approvers" are all approvers at the gate the request is being sent to.