Skip to main content
Planview Customer Success Center

Transitioning from Legacy to New Requests

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 possible. 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). The Legacy requests are targeted to be deprecated with the June 2020 release.

For those customers who are currently using Legacy requests and unfamiliar with new requests, see Key Differences Between Legacy and New Requests for more information.

Transition Approaches

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. NOTE: When both the old requests and the new requests are in use, references and links to the old "Requests" are automatically relabelled "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.

Approaches:

  1. Legacy Requests are Dead to Me - For customers who do not have audit needs, will finish out their in-flight legacy requests in the legacy system before they are deprecated, and need to create the appropriate request types with new requests and use them going forward.
  2. Can't Quite Let Go - For customers who are concerned about future audits that might be required post-legacy deprecation. This approach allows you to capture legacy data in a report(s) and either save it in PDF form, and/or export it to Excel and import into new requests. Similar to the "Legacy Requests are Dead to Me" approach in that you still need to analyze your needs and create request categories, but after building out your new request categories you can optionally import legacy data into new requests as needed.

Legacy Requests are Dead To Me

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.

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:

  1. What request types are still valid and will need to be included in the new Requests functionality.
  2. What request type forms/layout and fields are still valid and will need to be included in the new Request categories.
  3. 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.
  4. What sections you want to show on new, for example, to allow for requesters to more easily enter notes and attachments, possibly even scoring.
  5. 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.
  6. 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.
  7. 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
  8. What request reports and dashboards will need to continue to keep your stakeholders informed.

2. 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:

  1. 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.
  2. 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.

3. Set up your requests and default user views

It is recommended that you start simple when setting up your new requests, 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. And, if you will need to transfer any in-flight legacy requests into new requests (the second approach below), you will need to create a matching new request category or categories to receive the data.

The new Requests are configured via self-service admin: Admin > Setup > All Entities > Requests. You will need to configure the following new Request elements, please see the Stepping into Work Intake and Requests Management topic, Configure the Request section if you'd like additional details for each of these. Set up:

  1. Available Fields - existing Standard fields, new user-defined fields, and any field restrictions
  2. Category - sections to include and which should show on new, scoring profile, initial guidelines, and other details
  3. Gates - (if using gates) sections to include at each gate, gate approvers logic, gate entry and reminder notifications
  4. Gate Workflow - (if using gates) either sequential workflow or gate skipping logic
  5. Details - fields shown on new and at each gate, mappings to associated entity fields (see 'Ensure associated entities have request associations' above)
  6. Grid Columns - the fields you want shown by default as columns on the request grid view, and those your users can optionally add
  7. Cards - the fields you want shown on cards when users are in the request card view
  8. Searchable Fields - the fields you want to allow to be searchable within global search

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 for late first half/early second 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).

Transition Approach: Can't Quite Let Go

If you expect to be asked to provide legacy information to satisfy an audit or to answer questions about past requests, prior to deprecating legacy requests you can create a report that captures all your requests - from there you can save it as a PDF and/or Excel where you can refer back to it, or even extract it as OData. You may also want to create a report for each entity type the legacy requests may have created (Project, Task, Project Log), in case an item's name may have changed since it was created or to capture the relevant Project that a created Task or Project Log belongs to. If you really want to feed the legacy data back into the new request system, for example you have some legacy requests that may not have finished processing by the deprecation date in June, you can use the legacy request Excel report as the basis for the data import file for transferring legacy request data into new requests. Note that imported request data can be new or submitted, but cannot be imported to a particular gate.

1. Create Legacy Request Report

Create a Legacy Request report capturing all data needed for you and your auditors. This report can be created at any time and then run as needed, particularly right before deprecation. It can also be used later as the basis for the import file if you decide to import data into New Requests.

  1. Create a new List Report using the Target Organization, Category Legacy Request, and Report Source All Legacy Requests.
  2. In order to capture the basic legacy request data, from Available Fields add all the Legacy Request data that will be needed for audit or historical purposes. An easy way to do this is to simply drag and drop relevant All Available Fields folders into the Selected Fields grid, though you might want to reorder the dropped fields such as moving Title to the top. In particular add:
    • Fields from the Legacy Request/All folder.
    • Fields from each request type, which are found in the Legacy Request/Related/<request type> folders. For example, if you had four request types Enhancement Request, New Project Request, OOB Project Initiation Request, and Project Scope Change Request, you should see a folder of each of these request type's fields. 

item types.png

  1. In the Selected Fields grid reorder fields as needed to make it easier to digest as needed. You can also select any Sorting, Filter, or other List Options.

  2. Save & Run the report. Note that you can reduce the results to a particular legacy type by applying a filter when you run the report. For example, apply a filter to only show requests with a specific Legacy Request Type, such as Lab Update requests. Breaking up the data into multiple report results in this way may help if there is a large amount of resulting data or for easier audit management.

another filter.png

  1. From the resulting report window, to save the results to a PDF, select the Actions menu Print or Print with Details option. To save the results to an Excel file, select the report title drop menu Export and its Excel option.

print.png               drop.png

  1. Optionally, you can use OData to get legacy data out of PPM Pro and into an external reporting or BI tool of your choice (so long as that tool accepts OData), instead of or in addition to just exporting to a PDF or Excel. Using OData will allow you to continue to slice, dice, and report on the data you have extracted. See OData Setup for more details.

2. Create Project, Task, and/or Project Log Reports

Note: The following fields that contain links to a legacy request will disappear when legacy requests are deprecated:

  • Project entity: Legacy Request, Method ID 100472 and Legacy Request Score, Method ID 100484
  • Task entity: Legacy Request, Method ID 50099
  • Project Log/Issue entity: Legacy Request, Method ID 679

For completeness, in case one of the following is possible, you also may want to create and print/export entity level reports:

  • If there is a chance one or more of the projectstasks, or project logs could have a different Title from when they were created from a legacy request, you'll want to create and export/print a report for that entity. This report will allow you to cross-reference the current item Title, item ID, legacy request Title, and legacy request ID, with the Legacy Request report created earlier, just in case the legacy item title no longer matches the current item title.
  • If at least one task and/or one project log was created by a legacy request, you'll want to create and export/print a Task and/or Project Log report. This is because although the legacy request Item field lists the name of the task or project log, it will not include the project title and ID that the task or project log belongs to.

To quickly gage what item types could have been created from legacy requests, you can simply look at your list of legacy request types from within Admin > Setup > All Entities > Legacy Requests > Types (shown in the screenshot below).

2020-01-30_10-06-10.png

For each Item Type that you have a concern about, create a report. The following example is for the Projects Item Type.

  1. Create a new List Report using the Target Organization, Category Project and Report Source All Projects with Financials (for the other two item types, the report sources would be All Tasks or All Project Logs).
  2. For Field Selection, from the Available Fields in the Project folders, find and add ID and Title to the Selected Fields grid (for the other two Item Types, you would also add the Project field). You an also add any other fields you are interested in. 
  3. From the Project/Related/Legacy Request folders, find and add Id and Title. Optionally add Type to distinguish the projects created from legacy requests from projects that were not (unless you apply a filter at run time, see below). You can also add any other fields you are interested in.
  4. Save & Run the report. To reduce the results to just those projects that were created from requests, when you run the report you can create and apply a filter to only show projects with the appropriate Legacy Request Type. You also may want to take this a step further and apply a filter for one type at a time, if it would be helpful to break up the report results due to the amount of resulting data or for easier audit management.

filter.png 

  1. From the resulting report window, to save the results to a PDF, select the Actions menu Print or Print with Details option. To save the results to an Excel file, select the report title drop menu Export and its Excel option.

3. 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.

4. Optionally transfer Legacy Request data into new Requests

If you will have in-flight legacy requests that must be transferred into the new requests for further processing past the June 2020 deprecation date, you will want to either manually create those as new requests and/or import the legacy request data. Some things to note about transferring legacy request data to new requests via import:

  • You will need to have a new request category or categories configured to accept that data. That is, you will need to make sure your new requests categories include fields of the same format as the Legacy request fields you want to import (review the steps in the Legacy Requests are Dead to Me). Make sure that the new request category fields you are importing data into will be able to handle the data format, as you cannot import alpha data into a number field, nor can you import a value into a lookup list field that does not match one of the lookup list options. You also might want to ensure the new request category includes a field for Legacy Request ID if you’d like to cross-reference.
  • Imported requests cannot be set to start out at a specific gate in a workflow. So if you are importing legacy request data into a new request category that includes gates, you can only import it as a new request or as a submitted request, starting it at the first gate. From there if you need to move the imported requests along to later gates, you'll need to approve each to the appropriate gate. Or, you might consider importing your legacy requests into a new request category that has a first gate matching where the legacy requests were last in process. That way you could avoid having to manually move the imported requests along, provided representing the earlier legacy gates isn't needed.
  • You can use the legacy request report Excel file for your new request data import file. You will need to add a column for Request Category and ensure it contains the corresponding title of the new request category. You will also need to ensure that all of the fields required for the new request have values, at least those required for saving on new, but if the new request category includes gates then also those fields required to submit the request (assuming when you import you also want to submit the imported requests).
  • If you have a very large number of legacy request fields, it will help the data import performance and processing if you do the following to your import file:
    • Delete any field columns that you do not care to import.
    • Change or ensure that the column titles match the column titles of the example requests Generated Import File for New. Doing this and the bullet above will allow the data import wizard to automatically map fields if you select 'Map file fields to entity fields that have exactly the same title' when importing.
    • Consider importing data in batches, by type or some other meaningful way to organize your data.

5. Perform final report exports and 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, it's time to tie things up.

  1. If needed, run and export/print your legacy request report, and project, project log, and task cross-reference reports, for the last time.
  2. If you are ready before the June 2020 Product Release, when Legacy Requests will automatically be deprecated, submit a Support Case to hide legacy requests 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 so long as they have not yet been deprecated (but they will again be visible to all relevant users).
  3. If your legacy requests had attachments that you need to retain for audit purposes or to answer future questions, submit a Support Case to download Legacy Request attachments. This doesn’t have to be done before the June 2020 deprecation, as attachments can still be retrieved for a few months after. As part of the Support Case handling you will be given a set of instructions for how to download the attachments from an FTP site.