Permissions for requests are controlled with permission profiles (explicit permissions) and based on the user being the requester, creator, or gate approver (implicit permissions). Note that there is no request "owner" that can be controlled by an Owner permission profile. This is because who "owns" a request could vary and be any number of people including the requester, creator, and especially the gate approver. The request ownership changes from gate to gate, as each gate's approvers manage the request while it is at their gate (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 a request permission (such as Request > View or Request > Create) for either all requests or specific types/categories of requests. If a user has no permissions on requests, then the top-level nav will not be visible.
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.
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)
Implicit Approver Permissions (current user satisfies gate approval criteria)
Request user types are not eligible to perform approve/workflow actions.
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, Request users can never be approvers - even if it looks like you granted permission via a profile, it will be ignored.
Users can view/edit other's requests if they have explicit permission.
To see what explicit permissions a user has, see Permissions Explorer.
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
Instructions for creating the profiles are below.
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.
Gate approvers (see Configuring Gate Approvers) have implicit permission to do the following (no permission profile required):
The requester/creator has implicit permission to (no permission profile required):
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.
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.
We refer to these as explicit permissions.
An explicit approver is slightly different than an implicit approver in that an explicit approver can satisfy any one approval requirement for each criteria set. For example, if an approval filter specified "one user from All Resources, who is the requester's unit manager" a user who is an explicit approver could approve at that gate (without being the requester's unit manager, 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 (who isn't necessarily in the Finance group) 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. Remember, if you have multiple criteria sets, the explicit approver is evaluated for each set and can satisfy 1 approval for each set.
Note that an explicit/wildcard approver can also be an implicit approver if they happen to satisfy a filter criteria. However, an approval can only decrease any count requirement by 1 for each criteria set - meaning that if an approval filter has one set of criteria that 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 approval for that criteria set.
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.
The user/group/unit assigned to this permission will be able to submit any unsubmitted requests of any category type.
You can associate requests with projects, tasks, and issues (referred to as "entities").
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.
To copy data to an existing entity, the end user will need to have View permission on the request and Edit > Details permission for the associated entity.
For individuals who are not the requester, please be aware of the following:
Users can upload attachment on a request they don't own if they have Request > Edit > Attachment permission on the request
Users can delete attachments on a request they don't own if they have Request > Delete > Attachment permission