Request FAQs - End User

See also Request FAQs - Admin, Setup.

Q. I want to map my requester to the project owner field on an associated project.  I mapped the fields in SSA, and I see it on the second screen of the New Project wizard, but it is not selectable. 

A. Most likely the resource in the Requester field is not a full user - the Project Owner must be a full user. Helpful hint: if you hover your mouse over the Requester field, you should see some text that explains why the selection is invalid. In this example, the hover text displayed "The selected value is not allowed. Owner should be a full or team user."

Q. Why can't I see the Requests navigation icon at the top of my screen?

A. Make sure that you have a permissions profile that allows you to at least view requests - either globally (all requests) or specific types/categories of requests. If you don't have permission to view/edit any requests, then you won't see the tab. Similarly, if you have Create Request permission, this will allow you to create and then view and requests you created. See Setting Up Permissions for Requests.

Q. Legacy requests support automatic creation of a project or task or project log. How do I do that with the new requests?

A. Glad you asked! Auto-creation of an entity in the legacy requests is a bit of a misnomer. In order to create an entity from a legacy request you had to:

1. create a request type (category) for the entity type (meaning, you needed 3 request types to cover project, project logs, and tasks)
2. decide which type of entity you wanted to create BEFORE you started your request and then initiate your request with the specific request type
3. one the request is approved, fill out the wizard for the relevant entity

With the new requests, you do not need to create special request categories - any one category can support the creation of all target entities, provided the PPM Pro admin configures the category to do so. So you can evaluate the request and decide what kind of entity you want to create based on meta-data on the request. For example, if the meta-data (such as cost) suggests that the request is small and can be addressed at the task level, you can decide to create a new task in support of the approved request. Alternatively, if the meta-data indicates a much larger, longer-term effort, then you can decide to create a project. (With the legacy requests, if you determined that the request should be met with a task but was presented with a request type that could only create a project, you'd have to reject the request and start a new one that supported creating a task.)

Once you decide what kind of entity to create, you simply open the Associations tab and click the New button for the entity you wish to create. You will be presented with the same screen that was displayed with the legacy requests. Hopefully the flexibility of the new system outweighs the 2 extra clicks of opening the Associations tab and clicking New.

Q. Sometimes my request is approved at a gate by someone who is not in the Pending Approvers list - what's going on?

A. Most likely your PPM Pro admin has configured one or more users as "wildcard" approvers. These are users who are assigned a permission profile giving them Approve/Reject/Send Back to Prior gate permission. In a multi-approver scenario, a wildcard approver can satisfy one approval criteria. If that happened to be the last required approval, then the request will move to the next gate. For example, users who manage your request process may be wildcard approvers who can act in the place of an approver who may be out on vacation.

Q. Can we capture resource demand during intake process? 

Yes, through project associations. Once a project is associated to a request, you can capture the role and/or resource demand within that project’s Staffing view.

You will want to make sure that the request category has the Project Associations section configured for it. Make sure that relevant project categories also have Request Associations sections turned on, as that dictates which project categories can be associated to a request. You’ll also want to map relevant fields if you’ll be creating a project. Then, for each gate that you want the Project Associations tab to show up in, make sure it is configured to show at that request category gate.

During the work intake process, permitted users can create new project associations and/or add existing project associations. They can open the project from within the request to edit the role/resource demand.

If you use the Request process for project approval, we recommend you use project Status to distinguish when a project is still being evaluated/in workflow versus when it has been approved.

At a relevant gate where you would want to capture your demand, you would create the initial project with a Status such as “In Request Workflow” or something similar. If the request is ultimately approved, change the project Status as relevant. If the request is ultimately rejected, you can delete the project, or, change its Status to something such as “Rejected” if you need to keep the project around for governance/audit purposes. Be sure to make these statuses Implied Closed, that way when you run any Capacity & Demand Analysis that filter only on Implied Open projects, they won’t be included. You could also just eliminate those status from your filter directly…AND, if it helps, you could include the “In Request Workflow” projects for your Cap/Dem analysis to see impacts.

Another approach is to have a simplified project category for use with Requests that just has basic Details (those you’d map from the request) and the Staffing section, nothing else (unless there is other info you want to capture). Then you can change the project category to another that has the same Details plus others and also Staffing plus other sections.

Q. I am a request approver and during the request workflow I need to be able to get additional information from the requester. How can I do this?

A. 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 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, including instructions to select Place Back In Progress for the request once they have provided it. 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.

Q. I am creating a request that has sections, like Notes and Attachments. How come I can't access them (they are grayed out)?

A. You must save the request before the sections become active. You don't have to close the New Request modal - simply fill out the required field (denoted with red asterisks *) and then click Save. The sections will become active, and you can continue creating your request.

Q. On the Card view, I want to Group By a specific lookup list but I don't see the list in the Group By drop list.

A. The Group By field on the Cards view is the field that determines the content of the columns/lanes. You can group by any lookup list, provided your PPM Pro admin has configured it to be a Grid Column field (meaning it is available to put on the grid, though not required to be on the grid to use as Group By field). Check in the Configure Settings modal to see if the field appears in Available or Selected panel. If you don't see it, check with your administrator and ask that the field be configured for Grid Columns.

Q. Why can’t I copy field data from the request into xyz entity fields?

A. Check that your Admin mapped the correct request fields to the relevant entity category fields.

Q. Why are there 2 status fields? 

If you are creating requests with gates, the Gate Status list is provided as part of the workflow process. Its values - New, In Progress, Rejected, On Hold, Approved - automatically chronicle the request's status after each user action. You cannot change the Gate Status list items; note that a standard Current Gate field is provided as well. The Gate Status field will have no value for non-gated requests.

The simple Status list can be used with non-gated requests to move a request through a manual workflow and its values can be edited. It is recommended that you only use Gate Status for request categories that have gates and use simple request Status for request categories that do not have gates; it is not usually recommended that you have both Gate status and simple request Status on a request form at the same time, to avoid potential confusion for your users. See Managing Requests for more information.

Q. What happens if I create a project entity from a request using a project template, and I choose to copy fields from the request that already have values in the template?

A. The request data will take precedence over the template data.

Q. I approved a request and later received a notification that I had to approve it again? Why?

A. If a request is put on Hold and no changes are made to the gate flow, when the request is put back in progress (at the gate it was at when it was put on hold), all approvals will be wiped out. If the gate is configured to notify approvers when the request enters a gate, then putting the request Back In Progress will trigger this alert. Check to see if the request was recently Put Back in Progress by another user. 

Q. Can I see requests created by other users, or just my own?

A. By default, requesters/creators can see their own requests in the Requests grid. If you need to see all requests, or a specific category of requests, ask your Admin to give you permission using a permission profile.