This video provides an overview of each permission type. Duration: 5 min.
Access to PPM Pro entities (projects, resources, tasks, request, and so on) is controlled by permissions. For example, a user can have permission to view all projects (or a single project), but not to edit. Permissions take different forms, and how permission is granted depends on the entity type, the user type, and the action that needs to be performed. For example, a user might need permission to edit all projects, or view rates across the system, or edit one specific department, or access administrative features.
Permissions are granted using one or more of the following:
- Profile-based permissions - The most commonly used entities use this permissioning mechanism: assets, portfolios, projects, issues, tasks, (new) requests
- User type - User types determine the user’s general level of access to PPM Pro functions. For example, a Request user can only view and act on request management functions, whereas a full user can have access to all functions, can be added to standard groups, and can have admin access.
Standard group memberships - Standard groups grant certain permissions to group members. For example, members of the Publishing group have the ability to publish dashboards.
Administrator privileges - Granted to members of the Admin standard group.
Entity Team memberships/rights - This is the original (legacy) permissions model, and is being replaced by the profile-based permissions model. Requires users to be members of the entity team, with specific rights configured user-by-user. Applies to the following entities: Enterprises (Accounts), Divisions (Business Units), Departments (Programs).
Note that permission to create/view/edit Resources is granted by a combination of group membership (Resource group), and implicit permissions of unit manager/immediate supervisor. We plan to convert the Resource entity to the profile-based permissions model in the near future.
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.
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).
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.
PPM Pro has several user types:
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 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 specific 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 (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.