Skip to main content
Planview Customer Success Center

Setting Up 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, which are described in the table below (Requester and Creator Permissions: Pre- and Post-Submit). Any additional rights can be granted using a Global profile and assigned the requestor/creator/approver individually, or as part of a group or unit. 

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". See Permissions and Gates. These permissions can be granted on all requests, or per request category.
  • Implicit permissions for requesters and creator vary slightly if a request is submitted or unsubmitted. See Requester and Creator Permissions: Pre- and Post-Submit.

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 Permissions: Pre- and Post-Submit 

Implicit permissions for requesters/creators vary depending on whether a request is submitted or not; determining if a request is submitted varies if gates are in use or not.

  • If there are no gates for the request category, any simple Status field value OTHER than New or Proposed translates to "submitted"
  • If at least one gate is configured for the request category, the Gate Status field value will determine whether the request is "submitted" or not (any value other than New)

Creators, requesters, and approvers get "implicit rights" - these are actions they can take without needing a permission profile. The implicit permissions are determined by the "state" of the request - either submitted or unsubmitted. The following table describes the permissions that the creator/requester/approver gets - broken out by "limited access" user types (Stakeholder, Time, Request) and all other types (Full, Team). Note that only Full and Stakeholder user types can be request approvers:

  Implicit Requestor/Creator Permissions
(apply to requests where current user is requester or creator)

Implicit Approver Permissions
(apply to requests where current user is specified gate approver)

  Time, Request, Stakeholder All Other User Types Full, Stakeholder All Other User Types

Pre-Submission

  • With Gates - Gate Status field = New
  • Without Gates - Status field = Implied status IS Proposed

Full edit rights, including delete and score (if scoring set up)

Full edit rights, including delete and score (if scoring set up)

None None

Post-Submission

  • With Gates - Gate Status field = In progress, On Hold
  • Without Gates - Implied status is NOT Proposed
View Details

View Details, Edit Notes, and Edit Attachments

Place request on hold

Place request "back In Progress"

View Details, Edit Notes, and Edit Attachments

Place request on hold

Place request "Back In Progress"

Send back to previous gate

Approve/Reject

None

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.

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

There are two gate-specific profile-based permissions for users who are not approvers or who are requesters but require additional permissions:

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

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