|#||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.|
|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:
|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:
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:
Notifications are not configurable. They are always automatically sent each time an action is taken on a request.
|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:
|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:
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.|
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:
|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.|