Skip to main content
Planview Customer Success Center

Key Differences Between Legacy and New Requests

 

# Feature/Difference New Requests Legacy Requests
1 Associating to one or more existing/new entities - not turning into a single entity

One very important difference to get your head around is that the new Requests do not turn into a single entity; they act more like a carrier pigeon for request data and the associated entities to which this data is copied. Because of this and the fact that it is a self-service admin entity, you can change an existing request to another category if needed.

A request does not necessarily need to result in another entity, but if it does, then it can result in one or more projects, tasks, and/or issues/project logs, depending on how you configure the request category. The requester does not need to know up front what entity might result from the request. The data captured in the request can be copied to one or more new or existing entities, depending on which are configured to be associations to that request category. For example, a request's mapped field data, notes, and/or attachments could be copied to two existing tasks and also to a new project, or perhaps to two new projects, or perhaps to two existing project logs and one new project log, and so on. You can also report on request associated entities. Consideration should be given as to what possible entities might be needed when configuring each request category.

A request essentially results in a single entity, such as a project, task, or issue/project log. This means that the requester must know up front what entity type their requested work will result in. There is no way to change it to another type if the requester chooses the wrong request type. Also there is no way to split the information in a request into more than one entity.
2 Optional request guidelines, whether or not gates are used Each request category can optionally have an initial "Step 1 of 2" showing guidelines. These guidelines are from a rich text field and can therefore be easily formatted and include links. You can select to show this initial step whether or not a category includes gates. Requests must have an initial step of guidelines. 
3 Showing sections on "New" and copying categories

Per category, Admins can configure if the Notes, Attachments, Associations, and/or Scoring tabs should show on new. For all sections set to show on new, the new request modal shows all of the relevant tabs up front. These tabs are disabled until the request is saved, but once saved the modal remains open and the tabs become enabled right away. Requesters know up front that they will be able to add these items, adding them immediately after saving the initial request details or later as needed.

You can copy an existing request category so that you have a starting point for a similar request category; saves time and effort.

Allows a requester to save attachments and notes, but the requester will not initially see these sections within the new request modal. To access notes or attachments the requester must first save (and close) the request and then edit (and open) it, at which point these sections are available. Or, after submission they can add notes or attachments. Aside from the extra steps to reopen a request, a difficulty with this experience is that the requester may not realize that they can add attachments and notes; once the request is closed or submitted they may not think to open it again in order to add these items.

Legacy requests do not allow you to copy request types, each must be created from scratch.

4 Field creation and multiple mappings

Allows you to consistently create fields just like other self-service admin entities and easily map a request field to a different field on each possible entity category. For example, for a request category that allows associations to projects (with 2 possible categories "Maintenance" and "Product") and tasks (with 3 possible categories "Deliverable", "Enhancement", and "Milestone"), the Admin can map the request "Business Justification" field to the "Business Need" field on the "Maintenance" project category, to the "Business Justification" field on the "Product" project category, to the "Business Details" field on the "Enhancement" task category, and simply not map it to the other two task categories.

Request categories can draw from the same set of Available Fields, including user-defined fields (UDFs).

Gives you the power to create various user-defined fields and map them to the resulting designated entity's fields. However, you do have to jump through a few hoops to set this up (does not use standard self-service admin facility) and each request field can only map to a single field across the relevant entity's categories. For example, for a request type that results in a project (with 2 possible project categories "Maintenance" and "Product"), the request "Business Justification" field can only map to one project field of the same title across both project categories (both project categories will need to use the same field).

You must recreate a user-defined field for each request type, even if they are the same field; there is no common set of Available Fields to use across request types.

5 Requester capabilities and requesting on behalf of

One person can submit a request on behalf of another by simply editing the "Requester" field on the request (provided the request category has this field shown and editable). The Requester does not have to be a user, they can just be a resource.

Optionally the Admin can configure the request category to send a notification to the requester (provided the requester is a user, non-user resources are not notified) when submitted by another user, including the notification email subject and message.

Finally, depending on your organization's needs, requesters may be given permissions to view and even perform actions on requests made by other users.

You cannot change who the requester is; whoever submits the request is the requester.

Requesters cannot see requests submitted by others, to get an overview of what work requests have already been submitted and see if perhaps their work idea has already been submitted.

6 Limiting who has access to what request categories You have the ability to set who has what permissions on what request categories via permission profile models. For example, you can give all of your users access to view all request categories but only create certain categories. Or, you can grant two groups of users full access to create, view, edit, score, and so on, all request categories; grant Unit A create and view access to request categories 1 and 3; grant Unit B create and view access to request categories 1, 2, and 4, and so on. This enables you to ensure your users only see and can take action on relevant requests, decreasing the clutter in their views and preventing inappropriate request submission or actions. All requesters have access to creating all request types; you can limit certain request types to certain users using filters. Users must be on the gate approval team in order to view and take action on a request.
7 Gates...the power!
  • A request does not have to be part of a workflow, it can simply be a form for capturing information that can then be copied (or not) to other entities. Or, you can configure a request category to have 1 to n gates.
  • If a request does have gates, you can optionally show a first step of instructional guidelines; if a simple request category would not truly benefit from guidelines, simply do not configure it to have them and save your requesters the step and clutter.
  • Fields can be configured per gate to be required or not, have a default value or not, be shown or not, and if shown to be editable or read-only.
  • Requests must have at least one gate, for final approval and entity creation.
  • New requests always have an initial first step of instructional guidelines.
  • Fields can only be shown or hidden per gate; you cannot control if a field is required, has a default value, is shown as read-only per gate.
8 Required for saving vs. required for submission/approval

When a request category includes one or more gates, its requests can be saved as incomplete before submission or approval:

  • Any fields that must be completed with valid information in order to save the request are denoted with a red asterisk *; only mandatory required information such as the request title must be completed with valid information in order to save a request.
  • Any fields that must be completed with valid information in order to submit or approve the request are denoted with two red asterisks **; all required information must be completed with valid information in order to submit or approve a request. This allows a user to save a request with incomplete data, so that additional information can be gathered before submitting or approving it.
All required information (fields denoted with a red asterisk *) must be completed in order to save a request and transition it to the next gate. Some customers who need to gather additional information before submitting or approving a request will put dummy or placeholder information in required fields in order to save a request while they gather this information, so that they do not lose the information they have already entered. This workaround can lead to accidentally submitting or approving a request with this dummy information.
9 Notifications, including the nag-o-gram

You have the option to configure and send two types of notifications per gate, including configuring the email notification subject and message:

  • A notification, including a link to the request, that is sent only to relevant gate approvers when the request enters the gate
  • A reminder notification (or nag-o-gram, per one of our customers :), including a link to the request, that is sent only to relevant approvers who have not yet approved, recurring daily, weekly, or monthly as configured

Gate action (approve, reject, send back to prior gate, place on hold, place back in progress) notifications can optionally be sent at the user who is taking the action's discretion:

  • The action taker can select to notify the requester (provided they are a user), and once multiple approval logic is added per 13 below, notify other relevant gate approvers who have not yet approved
  • The notification is not configurable, but it will include any notes added as part of the action taken and a link to the request

Notifications are not configurable. They are always automatically sent each time an action is taken on a request.

Approval:

  1. When a request is submitted to an All Approver gate, everyone at the gate is notified.
  2. When a request is submitted to an Any Approver gate or Final Approver gate and Approver is selected, selected Approver is notified.
  3. When a request is submitted to an Any Approver gate or Final Approver gate and Approver is not selected, everyone at the gate is notified.
  4. When a request is fully Approved, the Requestor is notified.

Rejection:

  1. If a request is rejected at an All Approver gate, the original requester and everyone at the gate is notified.
  2. If a request is rejected at an Any Approver gate or Final Approver gate, no one at the gate is notified.
  3. If a request is rejected back to an All Approver gate, the original requester and everyone at the new gate is notified.
  4. If a request is rejected back to an Any Approver gate, the original requester and the owner at the new gate are notified. If no owner is set, then everyone is notified.
  5. If a request is rejected back to the Requestor (status Rejected), only the Requestor is notified.

General action:

  1. When a request changes gates, the Requestor is notified.
  2. When a request is Fully Approved, the Requestor is notified.
  3. If a request is Rejected, the Requestor is notified.
  4. If a request changes ownership, the Requestor and the new owner are notified.
  5. If request data (fields) are updated, the Requestor is notified.
10 Sending back to a prior gate, not THE prior gate, and rejection

You have the option to configure each request category to allow (or disallow) sending a request back to any prior gate it has already passed through before entering the current gate. For example, if a request has passed through gates A, B, C, and D, and is currently at gate E, then an approver or permitted user at gate E can select "Send Back to Prior Gate" and choose which gate, either A, B, C, or D.

Sending a request back to a prior gate is not a rejection, it is just a need for more review and/or information. If a gate approver or permitted user selects to "Reject" a request, then upon confirming the rejection, the request is removed from the workflow, has gate status of "Rejected", and becomes non-editable. If a mistake was made and the user wants to get the request back into workflow, a copy of the rejected request can be made, edited as needed, and then submitted.

Rejecting a request always moves it back to the previous gate, or to the submitter if there are no previous gates. Only users who have taken ownership of the request can reject it.
11 Placing a request on hold (and back in progress) Approvers and permitted users can select "Place on Hold" for a request and upon confirming, it will be removed from the workflow and have gate status of "On Hold". This allows a user to effectively remove a request from consideration but still make edits to it if needed. When the time is right, a permitted user can then select "Place Back in Progress" to put the request back in the workflow at the last gate it was at. There is no way to place a request on hold in Legacy requests.
12 Approving and final approval

Approvers and permitted users can select "Approve" for a request and upon confirming, if only a single approval was needed and the gate flow is sequential, the request will move to the next gate or become fully "Approved" if there are no other gates. See 13 and 14 below for future functionality coming soon for multiple approvals and gate skipping logic.

Approving a request moves it forward to the next gate, or to final approval if there are no more gates. Only users who have taken ownership of the request can approve it.
13 Card (kanban-style) view

Permitted users (those with implicit permissions such as requesters, submitters, and approvers, and those with global permissions granted by a permission profile) can view relevant requests in two ways:

  • Grid view, where the user can adjust what columns are shown, including those configured by the Admin. These columns can include user-defined fields.
  • Card view, where the requests are represented as cards that the user can group kanban-style by Gate Status, Current Gate (when view is filtered on a single category), and other discrete fields. Cards can contain up to 6 available fields from the full set of selected Details available fields.
Permitted users can view a grid of requests, adjusting a specific set of columns as needed. Columns do not include user-defined fields. All requesters can view their own requests, gate approvers can view the requests for which they are approvers, and users in the Organization group can view all requests.
14 1 to n various gate approvers

Advanced gate approver logic allows multiple and varying numbers of approvers based on request field properties. For example, you will be able to configure logic such as:

  • a single person who is the requester's unit manager must approve
  • any one person must approve who is a member of the IT Directors group when the requester has a role of Developer or they are a member of the IT unit, else all people must approver who are members of the Financial Directors group when the requester's unit is Finance, else any two people from the PMO group must approve
  • the ePMO unit manager must approve if the request's "ePMO review need" checkbox is selected, and the DCU unit manager must approve if "DCU review needed" checkbox is selected, and the QA unit manager must approve if the "QA review needed" checkbox is selected, else any 2 people from the Request Process Managers group must approve if none of these checkboxes are selected

You should be able to configure the relevant number of approvers and who should be in the pool of approvers based on your organization needs. Best of all, only those approvers which are triggered by the logic will receive gate entry notifications (if this notification is configured at that gate). For example in the last bullet above, if the ePMO and QA review checkboxes were selected, the ePMO and QA unit managers would both receive an email notification and would need to approve before the request can transition to the next gate, but if these checkboxes were not selected then the ePMO and QA unit managers would not receive an email and would not need to approve.

Approvers consist of the users specified to be on each gate's approval team and on the final approval team. An email notification will automatically be sent to all possible gate approvers unless a single approver had been selected as part of the request details, then only that person would be notified.
15 Gate skipping Advanced gate logic allows you to skip gates based on request field properties. For example, you can create gate logic to check if a request field for "Estimated effort (hours)" contains a value less than 100 and if so, skip directly to the last gate rather than going through unnecessary gates such as financials or security. This enables you to streamline the workflow so your requests can move through the process as swiftly as appropriate. There is no gate skipping capability in Legacy requests.
16 Activity Log

An "Activity Log" section is available to be shown at each gate. This section shows the workflow and activities the request went through, such as:

  • Workflow actions and progress, including approvals, rejection, when a request is sent back to prior gates, placed on hold, and placed back in progress
  • Notifications sent as part of the workflow and user actions
  • Activities related to notes, attachments, and scoring
There is a "Status" section with basic request details and a "Log" of gate flow activities such as submission, rejection back to prior gates, and approvals.