Permissions Overview

Permissions and Reports

Permissions around reporting vary by entity type. Entities that are under the profile-permissions model make all report sources visible to all users, and the report output is restricted to data the individual user has permission to see. For example, a user can see all project report sources (even Org-level sources), but the reports will display only the data from projects the user has permission to view. The Resource entity, for example, only offers Org-level report sources to members of the Organization group (because the Resource entity does not use the profile-based permission model). So users not in the Organization group will not be able to create/view Org-level resource reports. The user must be in the Organization standard group to view/create Org-level reports for the following entities: Resources, Departments, Divisions, Accounts, and Time reports.

In addition to having permission to see the report source, users also need permission to view/edit/delete reports. To create a report, you just need to have permission on the report source. 

Permissions and Associations/Entities Created from Requests

When creating associations between entities (for example, project to portfolio, request to project, task to request), there are always two entities involved. One is referred to as the "anchor" entity, and the other the "target". The anchor is where the current user is initiating the association - for example if the current user is creating an association from the request Associations tab to a project, then the request is the anchor entity and the project is the target.

To create an association, the current user must have Edit permission on the anchor entity, and View permission on the target entity.

Requests have the ability to create entities (and become automatically associated with the newly created entity). In this case, the current user must have Edit permission on the request, and Create permission for the entity type being created (Project > Create, for example).

Permissions and List Fields

List fields honor any permissions applied to the entity that populates the list field - both profile-based permissions and legacy team permissions.  

Profile-based permissions

For example, if you create a list field for an entity such as portfolios, the portfolios the current user can see in the list field are as follows:

• all portfolios if the current user has global permission to view all portfolios
• all portfolios of a specific category if the current user has global permission on a specific category
• if no explicit permissions granted, all portfolios owned by the current user
• the portfolios where the current user is on the team (with a permission profile)

Legacy team permissions (for entities that do not fall under the profile-based permissions model)

If the entity the list is based on does not use profile-permissions, like Departments/Programs, then the legacy "permissions" model applies. For example, if you have a list field for Departments, the current user will see only Departments where they are on the Department Team  with the "Can Create Parent Relationship for Projects" permission (or are in the Organization standard group).

Profile-Based Permissions

Profiles are containers of permissions that you configure to grant permissions to users, groups (of users), or units (another collection of users). Profiles can grant global permissions, which apply to all instances of an entity (like a project), or can be used to grant permissions to specific instances of an entity (like MyFinancialProject).

Profile-based permissions currently apply to Projects, Portfolios, Assets, Reports, Dashboards, Requests, and Filters. See About Profile-Based Permissions.

If you are using Centralized Staffing, then you will also use this feature to apply resource staffing permissions. See About Centralized Resource Staffing and Creating Staffing Permission Profiles for more information.

User Types

PPM Pro has several user types:

• Full

• Stakeholder

• Request

• Team

• Time

• WS API

• Integration

• Support

The user type determines some of the user's general level of access to PPM Pro functions. For detailed descriptions, please see User Types/Permissions.

Standard Groups

Standard groups give users permission to perform certain actions on all entities of a certain type. For example, a member of the Resources standard group has permissions across all Resources. Standard group memberships determine which spe­cific functions the user can access/perform - you cannot modify the permissions a standard group offers. For a full list of all standard groups and their implied permissions, please see About Groups.

Note that Administrative privileges are granted to Full users by membership to the Admin group. Administrators have access to all functions located under the Admin tab. For a full description of the administrative functions, please see About Admin.

Entity Team Permissions

Entity team permissions (often referred to as the "legacy" permissions) are a way to give users permissions on specific instances of an entity such as a specific department or enterprise. Generally, to give users permissions to all instances of an entity not covered by the profile-permission model, add them to the Organization standard group.

See About Entity Teams for more information.