The new Requests functionality is generally available with the November 2019 release. Any existing customers who are using Legacy requests should plan to transition to the new Requests as soon as is convenient. The Legacy requests can be used concurrently with new Requests - that is, you can continue to process existing Legacy requests while you begin using the new Requests, although these are two separate entities and cannot be reported on or managed together (you can have dashboards with reports for both entities). When both entities co-exist, the Legacy requests are retitled "Legacy Requests" and the new Requests are titled "Requests". The Legacy requests is targeted to be deprecated with the June 2020 release.
For those customers who are currently using Legacy requests, below are several key differences to keep in mind and an approach for making the transition to the new Requests feature easier for your organization.
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.|
|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.|
You can take different approaches to transitioning from Legacy to new Requests according to your business needs; definitely use what makes the best sense for your organization. Following is a common approach for you to consider as you work this out. If you have a Sandbox environment, you can try out the transition there, but you will need to recreate the new Requests in your Production environment when you are ready to transition your users. NOTE: When both the old requests and the new requests are both in use, references and links to the old "Requests" are automatically relabeled "Legacy Requests" and new requests have the label "Requests". Please make sure you are in the correct navigation area to manage each, and, to select relevant report sources and filters (Legacy Requests or new Requests) when creating and running reports.
1. Analyze your existing Legacy request types, workflows, reports and dashboards
Determine what changes you want to make to improve the request flow process given the new Request capabilities, identifying:
- What request types are still valid and will need to be included in the new Requests functionality.
- What request type forms/layout and fields are still valid and will need to be included in the new Request categories.
- What associated entities you want to allow for the new request category. Remember, you are no longer limited to having a request become a single entity. You might be able to combine one or more Legacy request types into a single new Request category by allowing more than one entity association.
- What sections you want to show on new, for example, to allow for requesters to more easily enter notes and attachments, possibly even scoring.
- What fields and sections are still needed overall, and what can be eliminated altogether or hidden at various gates. You now have the ability to not only hide or show a field per gate, but also decide if it should be required, editable, or have a default value. Do take advantage of hiding unnecessary fields at each gate, because the simpler and less cluttered the form, the happier the user and the faster the workflow.
- What field mappings to allow, or, not allow. You can easily reuse the same request field across request categories, mapping it to different associated entity category fields as needed. The request data can only be copied to associated entities for the fields that you map.
- If the request category will even need gates. If gates are needed, determine if you want to:
- include instructions/guidelines as a first step, and what those should be
- have multiple approvers at each gate, and who they should be based on properties of the requester or request itself
- send a notification to requesters when someone else submits on their behalf, and what the email subject and message should be
- send gate entry notifications to approvers at each gate and what the email subject and message should be
- send reminder notifications to approvers who haven't yet approved at each gate and what the email subject and message should be
- allow the request to be sent back to prior gates during the workflow
- allow the request to skip gates given the request field selections, to streamline the process
- What request reports and dashboards will need to continue to keep your stakeholders informed.
2. Set up your requests and default user views
The new Requests are configured via self-service admin: Admin > Setup > All Entities > Requests.
- Again, start simple, perhaps targeting a single category, as you can learn from setting it up first and then quickly add other categories later. Also consider future capabilities such as multiple approval logic and gate skipping; even though these are not yet available, you can set up the category now and configure it further once these capabilities do become available in future releases.
- Within Available Fields
- inventory the existing Standard fields to determine which you want to use
- create any new user-defined fields
- set up any field restrictions if there are fields you only want certain users to see, for example, if you want to hide certain fields throughout the workflow process from requesters or other users
- again, start simple, you can always add more fields later as needed
- Within Categories, set up your first category's details given the analysis of your Legacy requests from Step 1 above
- select what sections apply to the request overall (notes, attachments, associated entities, scoring), including which should be shown on new
- if the request will include scoring, pick a scoring profile (you can reuse scoring profiles you have already set up, or create a new scoring profile and set up its components)
- if the request will include rich text guidelines as a first step, shown when a new request is created
- if the request will include gates, configure as applicable request submission notification, and whether or not to allow it to be sent back to prior gates during the workflow
- Within Categories, if the first category will have a workflow with gates, for each gate configure
- which of the category's sections should appear
- the gate approver or approvers
- if a gate entry notification should be sent and if so, what its email subject and message should be
- if a reminder notification should be sent and if so, what its recurrence frequency and email subject and message should be
- Within Categories, if the first category has gates, then configure the gate flow
- Within Details, design the overall request form for the category
- Add group headers as needed and the available fields
- For each available field, configure its Variable Properties (on new and for each gate if the category has gates): required, default value, if shown and if so if editable
- For each available field that can be mapped and if the category has one or more associated entities, configure the field's mappings
- Within Grid Columns, layout the default columns and available columns that your users will see in their request grid.
- Within Cards, select what and how fields should appear on the card for that request category. Note that Available fields are derived from the selected Details fields; if you do not see a field you want to show up on a card, go to Details and make sure the field is shown there for the category.
- Within Searchable Fields, select what fields you want to allow to be searchable within global search.
3. Ensure associated entities have request associations
If your request will have associations to projects, tasks, or issues/project logs, you will need to go into each of these entities and edit the categories you want to allow to be associated to requests. This will enable you to:
- Control which entity categories can be associated to requests. For example, if your tasks have 3 categories "Deliverable", "Enhancement", and "Milestone", but you only want to allow requests to be associated to "Deliverable" and "Enhancement" and not to "Milestone", then you would edit the "Deliverable" and "Enhancement" task categories to ensure the "Request Associations" section is selected. This will ensure requests can only associate to (and copy request data to mapped fields for) these two task categories.
- Access associated requests from within individual entities. Once the "Request Association" section is configured for an entity category, whenever a user with permission to view its associations is looking at an individual entity, they will be able to see all of the associated requests for that entity. For example, if a project "Data Mining" is of a category associated to requests, when looking at the Data Mining project Associations section, there will be a panel for the Associated Requests for the project.
4. Grant permissions to relevant users
New Requests use the same profile-based permissions model as other entities, enabling you to grant global permissions to users, groups, and units that should be able to create, view or take action on requests (specific request categories or all request categories), to supplement the implicit request permissions a user will have by virtue of being a requester, submitter, or gate approver. When you are ready to begin allowing your users to use the new Request categories, you will want to set up these permissions to meet your organization's needs. Note that permitted users will see navigation links and icons for both "Legacy Requests" and new "Requests", and will need to be educated about using the Legacy requests view for monitoring any they had submitted or are approvers for and encouraged to use the new Requests view for all future request needs.
5. Setup reports and dashboards
Once you begin using the new Requests you can also begin reporting on them. Because the Legacy requests and the new Requests are two different entities, you will not be able to have a single report that combines information from both. However, you can create a dashboard that includes both Legacy reports and new Requests reports as needed. Currently the new Request reporting is basic, but it does allow you to report on associated entities which can be very helpful. There are several standard fields that help you manage and report on a request, specifically computed fields that show elapsed time. In addition, there is an activity log (provided the request category has been configured to show it), which is a tool for viewing all the high-level actions that have been taken on a request, giving visibility into how the request progressed through gates, including each approver's time of approval. Advanced reporting capabilities, particularly to support more gate and workflow analysis, will be added in a future release once the new reporting feature is completed (currently targeted within the first half of 2020).
6. Turn off the Legacy requests "New" button
Once you have set up all of your new Requests and are ready to begin using them instead of the Legacy requests, submit a Support Case to hide the "New" button in Legacy request views. This will allow you to continue to process and report on existing Legacy requests but prevent your users from creating new Legacy requests; your permitted users will only be able to create new Requests. Note that permitted users will see navigation links and icons for both "Legacy Requests" and new "Requests", and will need to be educated about using the Legacy requests view for monitoring any they had submitted or are approvers for and using the new Requests view for all future request needs.
7. Turn off the Legacy requests altogether
Once you are no longer allowing the creation of Legacy requests and no longer need to process or report on them, submit a Support Case to hide them altogether. This will remove the Legacy requests view and ability to report on them across your organization. Note that the Legacy requests are not deleted; they still exist but are just hidden, so if for some reason you did need to bring the view back you could submit another Support Case to turn them back on (but they will again be visible to all relevant users).