Skip to main content
Planview Customer Success Center

Profile-Based Permissions for Requests

Permissions for requests are controlled with permission profiles. Note that there is no request "owner" that can be controlled by an Owner profile. Instead of a request owner, there is a requester and a creator - if using gates, there is also a gate approver (see Permissions and Gates). These users have implicit rights - meaning they have certain rights as a result of being a requester/creator/approver that don't require a permission profile. Any additional rights can be granted using a Global permissions profile - referred to as "explicit" permissions. 

Note that the Requests navigation icon/label will not be visible to an end user unless they have permission (Request > View) for either all requests or specific types/categories of requests. 

General Notes

  • You can grant a user/group/unit global request permissions on all requests by configuring permissions for All Request Categories. For example, you might want to grant certain users the ability to view/edit all requests, regardless of type.
  • You can grant a user/group/unit global request permissions on specific types (categories) of requests by configuring permissions for specific request category(ies). For example, you might have five request categories/types, and you want to give certain users the ability to create/view/edit only requests of a specific category.
  • In addition to the basic permissions to view/edit specific request tabs and to create/delete/submit requests, there are two additional permissions of note: "Approve/Reject/Send Back to Prior Gate" and "Place on Hold/Place Back in Progress". These permissions are implicit for request approvers, and can be granted with permission profiles to fulfill certain scenarios, such as covering for implicit approvers who might be on vacation with a request awaiting their approval. See Permissions and Gates

Note: When setting up permissions for requests, you will only use the Global rule type. The other permission rule types do not apply to requests.

For general information about profile-based permissions, see About Profile-Based Permissions and Creating Permission Profiles.

Requester/Creator/Approver Implicit Permissions

Creators, requesters, and approvers get "implicit" rights - these rights allow those users to take certain actions without needing a permission profile. Implicit rights vary according to PPM Pro user type (Full, Stakeholder, Request, Time) and whether user is creator/requester or approver.

Implicit Creator/Requester Permissions (current user is requester/creator of request)

  • Prior to submission/save
    • all user types can edit a request they create (including Delete and Score if scoring set up), Submit
  • After submission/save:
    • all user types can view the request Details, and Associations section if the category includes it, Place Request on Hold (can edit request while on hold), Place Back in Progress
    • Full and Stakeholder user types can view the request Details, Edit Notes/Attachments/Associations, Place Request on Hold, Place Request Back in Progress

Implicit Approver Permissions (current user satisfies gate approval criteria)

  • Full and Stakeholder users who satisfy approval criteria can:
    • View/Edit Details
    • View/Edit Notes, Attachments, Associations, Scoring
    • Approve/Reject
    • Place Request on Hold
    • Place Request Back in Progress
    • Send Back to Prior Gate
  • After Final Approval:
    • View Details
    • View/Edit Notes, Attachments, Associations, Scoring

All other user types are not eligible to perform approve/workflow actions.

Explicit Permissions

If additional permissions are needed, then you must assign the user/group/unit to an appropriate (explicit) permissions profile. Note that even explicit permissions are subject to user type. For example, Time and Request users can never be approvers - even if it looks like you granted permission via a profile, it will be ignored. 

Time/Requests users can view/edit other's requests if they have explicit permission.

To see what explicit permissions a user has, see Permissions Explorer.

Configuring Permissions

The screenshot below reflects the areas on the Admin/Permissions page where you can configure permissions for requests. The red box surrounds the permissions that apply to all requests, regardless of category



permissions_req_hier.png

permissions_req_hier2.png

 Instructions for creating the profiles are below.

Granting permission to edit all requests

  1. Navigate to Admin/Permissions.
  2. Create a New profile by clicking New and then naming the profile (for this example, we'll use Global Requests). Note that you can edit an existing Global profile and add the permissions from step 3.
  3. In the Permissions Hierarchy, click All Request Categories > Edit > Details (check Notes and Attachments if you want all users to be able to view and edit those as well).
  4. Under Permission Rules, choose Add > Global, and select the user, group, or unit to assign to this profile.
  5. Click Save.

Whoever you assign to the Global Requests profile will have full edit access to all requests. You can create variations of this profile - for example, you can grant global view only permission to all requests.

Granting permission to edit specific request types/categories

  1. Navigate to Admin/Permissions.
  2. Create a New profile by clicking New and then naming the profile (for this example, we'll use Abstract Business Case requests, which is the name of a request category in this example). 
  3. In the Permissions Hierarchy, click All Request Categories > Abstract Business Case request > Edit Details (check Notes, Attachments, and Scoring if you want all users to be able to view and edit those as well).
  4. Under Permission Rules, choose Add > Global, and select the user, group, or unit to assign to this profile.
  5. Click Save.

Permissions and Gates

Gate approvers (see Configuring Gate Approvers) have implicit permission to do the following (no permission profile required): 

  • approve/reject request
  • send request back to prior gate
  • place a request on hold
  • place a request back in progress

The requester/creator has implicit permission to (no permission profile required):

  • place a request on hold
  • place a request back in progress
What are Implicit Permissions?

An implicit permission is one a user gets by being a certain type of user, or by having a certain relationship with an entity (such as project owner or request creator or task owner). As mentioned above, an approval filter evaluates to a user, group (members), or unit (members) who is the gate approver; these users have implicit permission to approve (reject, and send back to prior gate) the request at the gate where they satisfy the approval filter criteria. They do not get this approval power any way other than being the result of the approval filter.

We refer to these users as implicit approvers.

What are Explicit/Wildcard Permissions?

There are two gate-specific profile-based permissions for users who are not approvers or who are requesters but require additional permissions. These permissions are typically granted to accommodate a request manager's desire to ensure that a request is not held up at a gate due to a gate approver being out on vacation.

  • Approve/Reject/Send Back to Prior Gate - This permission grants a user/group/unit the ability to approve, reject, or send a request back to a prior gate (provided that the request category supports the "Allow request to be sent to prior gate" option). The permission can be granted globally or per request category. Note that gate approvers have these permissions implicitly.
  • Place on Hold/Place Back in Progress - This permission grants a user/group/unit the ability to place a request hold, or change the status to back to In Progress. The permission can be granted globally or per request category. Note that gate approvers and the requester have these permissions implicitly.

We refer to these as explicit permissions.

An explicit approver is slightly different that an implicit approver in that an explicit approver can satisfy any one approval requirement. For example, if an approval filter specified "one user from All Resources," a user who is an explicit approver could approve at that gate (that is why the explicit approver is also referred to as a "wildcard"). If an approval filter specified "two users from Group Finance," then one explicit approver could satisfy the requirement of one of the two users. The second user from Group Finance can be satisfied by either a member of Group Finance, or another (different) wildcard approver.

wildcard.png

Note that an explicit/wildcard approver can also be an implicit approver. However, an approval can only decrease any count requirement by 1 - meaning that if an approval filter requires 2 members of Group Finance to approve a request, and one user is a member of Group Finance and a wildcard approver, that user can satisfy only one of the criteria. 

Using Explicit Submit Permissions

Similar to the wildcard approver (though this has nothing to do with approvals), you can configure a backup to a request creator. Remember that request creators get implicit Submit permission for any request that they create. If you need a different user to be able to submit a request created by someone else, you can assign the Submit permission globally (all requests) or for specific request categories. This person can submit the request on behalf of the creator if, for example, the creator goes on vacation before the request is submitted. Note that generally speaking, this is not a common use case. 

  1. Navigate to Admin/Permissions.
  2. Create a New profile by clicking New and then naming the profile (for this example, we'll use Submit Requests - Global.
  3. In the Permissions Hierarchy, click All Request Categories > Submit 
  4. Under Permission Rules, choose Add > Global, and select the user, group, or unit to assign to this profile.
  5. Click Save.

The user/group/unit assigned to this permission will be able to submit any unsubmitted requests of any category type.

Permissions and Associations

You can associate requests with projects, tasks, and issues (referred to as "entities").

  • You can add an association from a request to an entity (project, task, issue) -  requires Request > Edit > Details permission and at least View permission on entity). Note that the request must be configured to show the appropriate association(s); if you do not see "Associated Project" in the Associations tab of the request Details modal (or no Associations tab at all), please contact your PPM Pro administrator.
  • You can add an association from an entity to a request (requires edit permission on the entity and at least Request > View permission). Note that the entity must be configured to show Request Associations; if you do not see "Associated Requests" in the entity's Associations section (or no Associations section at all), please contact your PPM Pro administrator.
  • You can remove an association from a request to an entity (requires Request > Edit > Details permission and at least View permissions on the entity). 
  • You can remove an association from a entity to a request (requires Edit permission on the entity and at least Request > View > Details permission on the target request).
  • To add an association and create new entity (project, task, issue), the user must have Request > Edit > Details permission on the request and Create permission for the target/new entity.

Permissions and Creating an Entity from a Request

To be able to create the new entity and populate the mapped values, the end user will need to have edit permission on the request and create permission for the designated entity.

Permissions and Copying Fields to other Entities

To copy data to an existing entity, the end user will need to have Edit permission on the request and Edit > Details permission for the associated entity. 

Permissions and Notes, Attachments, Details

For individuals who are not the requester, please be aware of the following (same applies to attachments):

  • Users can create notes on a request they don't own if they have Request > Edit > Notes permission on the request 
  • Users can delete notes on a request they don't own (their own notes or notes created by others) if they have Request > Delete > Notes permission 
  • The note owner (whether or not the requester) has implicit permission to edit their own notes
  • The note owner (whether or not the requester) needs explicit permission to delete any note (even one they own).