Skip to main content
Planview Customer Success Center

Stepping into Permissions Management

PPM Pro provides great flexibility in managing what users can see and act on what entities, but with great flexibility comes great complexity (and responsibility ;). It is easy to get lost in the weeds of permissions management, so the purpose of this topic is to clear cut a path for you and enable you to more easily manage your users' permissions and access given your company's needs. If you have any questions about any of the following or other permissions management needs not addressed here, please contact Customer Care or Consulting Services. If you have another example or a helpful tip not portrayed below that you would be willing to share, please email productmanagement-ppmpro@planview.com and we will gladly add it!

The steps covered in this topic include:

Step 1: Inventory your users' permission needs

Step 2: Ensure users have appropriate user types

Step 3: Add users to legacy entity teams

Step 4: Create/update groups and organization hierarchy for easier permissions granting

Step 5: Add users, groups, and/or units to standard groups

Step 6: Review and update your permission profiles

Step 7: Maintain and trouble-shoot permissions

 

Before You Begin

The key to getting your arms around permissions management is first understanding what permissions your various users need and then determining which of the various ways users can be granted access to an entity (project, resource, tasks, request, and so on) should be used, ideally to minimize long term maintenance. The permissions a user has are additive across the 5 different ways in which they are granted permissions.

Three of these ways, User Type, Standard Group Permissions, and Profile-based Permissions, are where you will primarily be living when it comes to permissions management. The fourth, Legacy Team Memberships, only applies if you are using Enterprises (Accounts), Divisions (Business Units), or Departments (Programs); most customers are no longer using these because the organization hierarchy is becoming a more powerful method for organizing and granting permissions in lieu of these legacy entities. The fifth way is through Implicit Permissions, which really are automatic and do not require your management, they are just good to be aware of (these are covered in Step 7).

5 squares.png

A user's permissions are the combination of all permissions granted in these ways

 

 

Step 1: Inventory your users' permission needs

Before you begin assigning or updating permissions, take a fresh inventory to determine what permissions are needed by what users. You'll particularly want to ensure you identify which users need the same permissions, because it is much easier to maintain your user permissions when you can manage them in sets of users, for example as groups or units of users. It is strongly recommended that you create an initial spreadsheet or chart of your sets of users to help organize their needed permissions so that you can reference it when managing permissions (here is a Sample Permissions Spreadsheet in case it helps). Some considerations that might help you as you inventory include:

  • How much power does a user really need? Consider starting simple and assign bare minimum permissions to your users, as it is much easier to give more permissions in the future than to give them up front and need to take them away later.
  • Do people with the same role, or other attribute, need the same permissions? If so, you could consider grouping these people when granting permissions (Step 4).
  • Do people within the same organization unit and child units need the same permissions? If so, you could consider granting permissions to that unit as a whole (Step 4).
  • Do unit managers need staffing permissions? Do non-unit managers or other users need staffing permissions? If so, you'll want to consider Unit Manager and/or Special Access rules for assigning specific profile-based staffing permissions (Step 6).
  • What permissions will entity owners need, and do those permissions vary by entity, entity category/class (for projects/portfolios) or are they the same across all entities? This will help you determine any special permissions for owners across or for entity types, categories, and classes (Step 6).
  • Are there different sets of permissions needed for entity team members, such as some team members being able to edit anything on the entity, others editing certain things, and still others mainly just having view access?  Will different types of entity team members, like project or portfolio team members, need different permissions? This will help you determine if you need to create different profiles for different types of team members (Step 6).
  • Do Administrators need access to more than the Admin view? If so you'll need to assign them relevant entity permissions (Step 6).
  • Are there any users that need all permissions? Are there any users that only need a specific permission, such as view access? Identify the range of permissions needed (see all steps).

Step 2: Ensure users have appropriate user types

Resources must be users in order to access PPM Pro and to be granted permissions. When users are created, they are assigned a user type, which inherently gives them the ability to take advantage of certain permissions and not others. Think of the user type as a way of automatically constraining what permissions are possible. For example, a Request user type will allow a user to be granted permissions on requests, but not on any other entity (even if a Request user had a profile-based permission that gave all project view permissions, they still could not view projects because their user type limits them to only requests).

The four user types that apply to people who will be accessing the PPM Pro user interface are:

  • Request User - The main reason for assigning a Request User is to only allow users to be able to create, submit, view, and/or score requests. Request users cannot be given access to any other entities, cannot be added to standard groups, and cannot have Administrator permissions.
  • Stakeholder User - Stakeholder users can be granted profile-based permissions for creating, viewing, scoring, and/or approving requests. They can also drill down from a report or dashboard to view any entity in the system that they have been given permission to view through profile-based permissions. Stakeholder users cannot be given other types of access (such as edit) to any other entities, cannot be added to standard groups, and cannot have Administrator permissions.
  • Time User - Time users automatically can enter timesheet data (once they have a Timesheet Activation Date on their user details), view tasks that they own and edit a subset of fields, view tasks they are scheduled to, and view and edit issues/project logs that they own. They also can be granted profile-based permissions for tasks, issues/project logs, and creating, viewing, scoring, and/or approving requests, for example to be able to edit their tasks and/or issues/project logs. And, they can view reports about their tracked time, if set up for and granted access to by another user. Time users cannot be given access to any other entities, cannot be added to standard groups, and cannot have Administrator permissions.
  • Full User - Full users can be granted profile-based permissions for all entities and their functions. They also can be added to standard groups and can have Administrator permissions.

Screen Shot 2019-01-21 at 12.34.18 PM.png

Because the different user types allow different types of access, you'll want to make sure your existing users and new users have the appropriate user type. When you create or edit a user, choose the user type based on the user's needs:

Screen Shot 2020-04-13 at 12.52.19 PM.png

Note that if you are creating or editing a user and receive a message that you do not have enough licenses for the selected user type, please contact Customer Care or your Account Executive. User types are tied to license, which in some cases can be adjusted (for example, increasing the number of Request Users, as their licenses are effectively free) or potentially shuffled or added based on your needs.

Step 3: Add users to legacy entity teams

Hopefully you can skip this step to save you time and maintenance. There are still some legacy entities in PPM Pro that do not have the ability to have profile-based permissions: Enterprises (Accounts), Divisions (Business Units), and Departments (Programs). If you do not use these entities, excellent, do skip to Step 4! If you do use these entities, then a Full user may be granted permissions on them by being a member of the entity's team, with any of the following rights configured user-by-user:

  • Edit this Item - Edit the entity's Basic Info/Details or delete the entity
  • Create <child entity> - Create children of the entity, for example, if the user is a team member of a Division this permission gives them the ability to create Departments
  • Edit entity team - Edit the entity team membership
  • View Rollups - Allows user to view the entity's Rollups tab and "To Date" financial fields in Reports for the entity
  • Can Create Parent Relationship with Projects (Departments only) - Populates the Department droplist with any department for which the user has this permission. In the past, projects were required to belong to a parent department; this is no longer a requirement. However, if you want to use a department in conjunction with a project, you need to have this property for each department you want access to.

For any of your users who need one or more of the above permissions on Enterprises/Accounts, Divisions/Business Units, and/or Departments/Programs, add them to the relevant entity's Team with appropriate permissions (see Creating Permissions-Based Entity Teams).

Screen Shot 2019-01-21 at 9.18.04 AM.png

 

Step 4: Create/update groups and organization hierarchy for easier permissions granting

Once your user types are in good shape and before you begin granting other permissions, use the inventory you took in Step 1 to identify any common sets of users that you could potentially create groups for or make use of existing organization hierarchy units. You'll want to update existing groups and organization hierarchy memberships and/or create new ones, so that as possible you can apply the same permissions to these groups and units. Both groups and units can be assigned to standard groups (Step 5) and to profile-based permissions (Step 6). Taking advantage of groups and units can simplify your permissions management because you don't need to add (and continually update) user by user.

Groups

The two types of groups you can create are user-defined and filter-based. The primary difference between these two groups is how their members are identified. With user-defined groups, you explicitly add individual users, other groups, and/or units. This is a great group to create if you need to be able to ensure only certain people are part of the group. The downside is that you will need to manually maintain this group to ensure the correct people are in it. With filter-based groups, a resource filter determines who the members are. This is a great group to create if you want to ensure all users with a certain property are automatically included, meaning much less maintenance for you. The downside is that you need to make sure the resource filter you use pulls in only those users that you want in the group.

For example, if you know that certain roles (such as financial managers) will need the same permissions (such as viewing all financial information across the organization), you can create a filter-based group focused on that role and then add it to a standard group (such as Internal Cost Visibility). Or, if you have a set of project managers who need access to view all projects across an organization, you can create a filter-based on that role and assign the group a global rule in profile-based permissions (such as Full View Access). Another example of a filter-based group is based on a common property shared by a group of users, such as a particular set of skill categories or sharing the same timesheet approver.

Units

Unit membership hopefully is already organized in a meaningful way for your company. Oftentimes all members of a unit will need similar permissions, allowing you to add them to user-defined, filter-based, and/or standard groups as well as to a global rule in profile-based permissions. For example, if you know that all members of an organization hierarchy unit (such as Finance) and any child unit members should have the same permissions (such as financial data access), you can add that unit to a standard group (such as Billable Rates and Internal Cost) or global rule in profile-based permissions (such as Organization Finances - Full Edit).

Step 5: Add users, groups, and/or units to standard groups

The ability to access certain views and functions in PPM Pro have not yet been included in the profile-based permissions model. A Full user, other group, and unit may be granted permissions to these views and functions by being added as a member to certain standard groups (other user types will not appear for selection within the standard group's Add Team Member modal).

 

Screen Shot 2019-01-21 at 9.14.47 AM.png

 

Based on your permissions inventory (Step 1), consider the following needs and add relevant Full users, groups, and/or units to standard groups as appropriate:

User, Group, and/or Unit Permissions Need Add to Standard Group FYI
Access to Admin view and functions Admin
  • Admin group members just get access to that view, they are not granted permissions on any entities
  • In addition to adding a user directly to this group, you can also add a user to the Admin group when creating or editing the user and selecting the 'Admin?' property
  • If a user is not in this group, they will not see Admin in their top level navigation
  • This is a very powerful capability and should not be granted lightly or to many users
View all bill rate, billable amount, profit and margin information, including in rollups and reports Billable Rates
  • This group is only available if the Billing Rate feature has been turned on
  • Because billing rates may be sensitive information, only certain users should be members of this group
Access to the Capacity & Demand facility Capacity and Demand
  • Note that in order to actually see content on which to perform capacity and demand analysis, the users, groups, and units also will need to have separate profile-based permissions to view the availability of relevant resources and projects
  • If a user is not in this group, they will not see the Capacity and Demand views
View all internal cost, profit and margin information, including in rollups and reports Internal Cost
  • If a user is not in this group, reports and rollups will not show internal costs
  • Because internal costs may be sensitive information, only certain users should be members of this group
  • Generate reports for the Organization, Division, Enterprise, Requests and Time
  • View basic information for resources (but not internal rates or attachments to individual resource records)
  • If you are using one or more of the legacy entities (Enterprises/Accounts, Divisions/Business Units, Departments/Programs), create/edit these and view all information including attachments and rollups
Organization  
Publish and unpublish dashboards Publishing Users, groups, and units who need to publish dashboards should be granted separate profile-based permission to Create dashboards
  • Create new resources
  • View and edit all existing resource information, including a resource's internal, billable rates, and HR Notes
  • View pri­vate attachments on resource records
Resource  
Make corrections or additions to users' timesheets from Organization > Manage Time & Expense > Resource Time Timesheet Manager This is a very powerful capability and should not be granted lightly or to many users

Note that there are a three other standard groups that convey permissions that you are unlikely to see, due to the feature being deprecated or in low usage. If you see these standard groups, please see About Groups for their permissions: Enterprise (Account), Fixed Bid Manager, or Expense Manager.

 

Step 6: Review and update your permission profiles

ICYMI, what is a Permission Profile?

Profile-based permissions can be applied to any user type and are used to grant granular permissions on various entities. An individual profile holds the permission(s), plus the scope for how to grant the permissions, who to grant the permissions to, and on what entities.

Profile = Permissions + rule + who + entity

  • The "permissions", represented in the Permission Hierarchy tree, include create, view, edit, delete, and other entity-specific functions.
  • The “rule”, represented in the Permission Rules, determines the scope of the permissions:
    • Global - Grants selected permissions to ALL instances of an entity (all projects or all projects of a given category, for exampel) for the specified users, groups, and units.
    • Team - Grants selected permissions on AN entity instance (a specific project, for example, rather than all projects) when a user, group, or unit is added to that entity instance's team (such as a project team) with the current profile.
    • Owner - Grants selected permissions to entity owners. Note that entity owners get implicit rights to view and edit much or all of the details of the entity they own (such as view and edit project details), but you can use an owner profile to augment these permissions (such as Delete project or Edit all project sections). See Implied Permissions for Entity Owners for information about the implied rights for each entity owner. 
    • Unit Manager - Grants only selected resource permissions to organizational hierarchy unit managers on the resources in their units.
    • Special Access - Grants selected resource permissions on a unit when a user, group, or other unit is added to the unit's Special Access list.
    • Association - DO NOT USE: With the ability to now grant permissions on projects of specific categories, the Associations rule type is pretty much obsolete and we will be deprecating it. Please avoid using, and if this confuses you, please post a question in Community Discussions or enter a support case to ask for assistance.
  • The “who”, which is determined based on the Permission Rules or when adding to a team or special access list, specifies who is granted the permission - an individual user, a group, or a unit.
  • The “entity”, also represented in the Permission Hierarchy tree, is any of the supported entities: projects, tasks, issues, portfolios, assets, reports, filters, dashboards, organization finance settings, organization internal rates, and new requests. 

 

Screen Shot 2019-01-23 at 2.21.20 PM copy.png

Things to Keep in Mind

As you consider existing and potentially new permission profiles, here are some tips and additional info that may be of help.

  • There is no right or wrong way to set up permissions profiles - So relax! The best design is to have the set of permission profiles that make sense to you so that you have the easiest time managing them (along with ensuring users have the correct permissions, of course!).
  • A user can be part of more than one profile, use this to your advantage - A user's permissions will be the combined set of all their profile permissions (as well as permissions granted by standard groups and so on mentioned earlier). If one profile grants a user only view on all projects while another profile grants that user edit on all projects, then the user will be able to view and edit all projects. By the same token, if one profile grants a user the ability to create one category of requests while another grants that user the ability to create all categories of requests, then they will be able to create all categories of requests; the user might not need to be on that first profile at all, unless it is granting other needed permissions which is perfectly fine. This ability allows you to create different profiles for different sets of permissions so that you can easily apply multiple profiles to your users, which in turn can help you decrease the overall number of profiles you need to maintain (for example, you shouldn't have to create or maintain one profile for every user).
  • User type constrains what permissions actually apply, use this to your advantage too - Full users will have exactly the permissions that their profiles specify. Other user types will only have a subset of entity permissions no matter what permissions are selected in their assigned profiles. For example, a Request user will only have permissions relating to requests; even if a Request user has a permission profile that includes project permissions, those project permissions simply will not apply. This is actually great, as you don't have to worry with making sure Request users are only on a profile that solely has request permissions; you can piggy back off of a profile that has the relevant request permissions safe in the knowledge that the other permissions won't apply, which means much less maintenance for you.
  • A profile can have any number of rules, use this to your advantage too, too - There is no limit to the number of rules you can include in a profile. For example, in one profile you can include a global rule that grants global permissions to one or more users, as well as a team rule that offers the same permissions for use on an entity instance. Having more than one rule to a profile will cut down on a lot of clutter and make maintenance easier.
  • Portfolio and Asset permissions can be granted for all classes or individual classes - Portfolio/asset classes allow you to have completely separate sets of portfolios/assets. Each portfolio/asset class is represented as a top level navigation area within PPM Pro. When granting permissions on portfolios and assets, you can grant permissions for ALL portfolios and assets, or, to individual classes of portfolios and assets. This is great if you need to ensure different users, groups, or units only see or act on certain portfolios or assets.
  • Project and new Request permissions can be granted for all categories or individual categories - Categories allow you to set up various types of entities. Different categories can have different sets of fields displayed on the entity's Details, as well as a different sets of sections or component tabs such as Notes, Attachments, and others. When granting permissions on projects and requests, you can grant permissions for ALL project categories and ALL request categories, or, to individual categories. This is great if you need to ensure different users, groups, or units only see, create, or act on certain types of projects or requests.
  • Be familiar with the various entity permissions - Most of the permissions in the Permission Hierarchy tree are fairly straightforward, such as being able to Create, View, Edit, and Delete an entity and/or its sections such as Details/Additional Details/Settings, Attachments, Notes, and so on. Here are a few special or unique permissions that you may or may not be familiar with (note that all Request permissions only apply to the new request feature):
    • Project > Edit > PMO Locked Fields - Only visible when PMO Locking is turned on, which allows you to restrict the editing of a field (or fields) to permitted users
    • Organization Finance Settings - Allows permitted users to View and/or Edit the Organization/Finances/Settings contents
    • Organization Internal Rates - Allows permitted users to View and/or Edit the Organization/Finances/Internal Rates contents
    • Request > Submit - Allows a permitted user to submit a request, whether or not the user is the creator or requester
    • Request > Approve/Reject/Send Back to Prior Gate - Allows a permitted user to approve, reject, or send back to a prior gate (if the request category has this option selected) a request, whether or not the user is a gate approver
    • Request > Place on Hold/Place Back in Progress - Allows a permitted user to place an in progress request on hold or to place a held request back into progress, whether or not the user is a creator, requester, or gate approver
    • Resource > View > Availability - Allows permitted users to view resource availability in the Resource Workbench (Home/Resources view)
    • Resource > Propose - Only visible when Managed Staffing is turned on, allows permitted users to propose resources to fulfill demand from their pool of resources
    • Resource > Process Requests - Only visible when Managed Staffing is turned on, allows permitted users to act on a staffing request by fulfilling demand, partially fulfilling demand, or declining the request (includes access to the Resources/Staffing view)
    • Resource > Staff Directly - Only visible when Managed Staffing is turned on, allows permitted users to fulfill demand from their pool of resources
  • Inspirations from the Project Permissions Cookbook - To help get your arms around permission profiles, check out the Project Permissions Examples Cookbook for common project permission scenarios, many of which can also be extrapolated to other entities.

Review and Update

Look through your existing permission profiles and your inventory from Step 1, to see if you already have the right coverage for your sets of needed permissions or if you need to make adjustments and additions.

  1. First, select an existing profile and look at its Permission Hierarchy tree selections to see if it matches one or more of the user sets' needed permissions from your inventory. It doesn't have to match all selected permissions, again because you can apply more than one profile to users (if it doesn't match any, this is a candidate for removal, see Step 7 for maintaining permissions and removal), but it should match at least some permissions.
  2. Given the matching selected permissions and your user sets, look at the profile's Permission Rules to see if the relevant user sets and entities relating to the selected permissions are identified:
    • Global rules are explicitly identifying the users, groups, and/or units needing those permissions across all relevant entities
    • Team rules exist for the relevant entity so that the users, groups, and/or units needing those permissions can use the profile when added to specific instances of an entity team
    • An owner rule exists if the selected permissions need to apply to owners of the relevant entities
    • A unit manager rule exists if the selected permissions include Resource permissions and need to apply to organizational hierarchy unit managers for the resources in their units
    • A special access rule exists if the selected permissions include Resource permissions and need to apply to organizational hierarchy unit special access members (users, groups, and/or units) for the resources in that unit
  3. If there are any rules that should apply that are not present, add the missing relevant rules.
  4. If there are any rules that should NOT apply that are present, either make the rules inactive or delete them. NOTE: If these permission profiles have been in use for a while with existing users, any users who have had these permission will no longer have them, so you will need to be prepared to handle user questions around why they can no longer access what they used to and/or proactively notify your users that permissions are being adjusted (with a good explanation of why).
  5. Consider if additional permissions should be selected within the Permission Hierarchy tree, given the Permission Rules and relevant user set needs from your inventory. If so, select those additional permissions.
  6. Review the profile's Title and Description to see if those are still representative of the selected permissions and rules/user sets. Make any changes to these to help clarify.
  7. Make sure you indicate in your inventory which users sets and permissions have been handled by this profile, for example, by bolding or changing the colors of permissions and user sets that have been addressed and/or by noting applicable profile titles.
  8. Repeat steps 1-7 for each of your existing profiles.
  9. If any of the profiles had applicable team rules, you'll want to add the user to the relevant entity teams with that profile.
  10. If any of the profiles had applicable unit manager rules, you'll want to make sure the user is a unit manager on the correct unit.
  11. If any of the profiles had applicable special access rules, you'll want to to make sure the user is added as a special access member on relevant organization hierarchy units.
  12. Review your inventory and see if there are any user sets and permissions that have not been captured in your existing profiles. If there are, create any new permissions profiles to ensure all of your remaining users sets' permissions are accounted for.

 

Step 7: Maintain and trouble-shoot permissions

One you have all of your users set up with their needed permissions, there are various ways to help maintain these permissions going forward, for example, when you need to add new users to PPM Pro, change permissions when a user's role changes, trouble-shoot questions such as why a user can not see a certain entity (or can see a certain entity they shouldn't!), and so on. It is strongly recommended that you keep your inventory from Step 1, updating it as needed, because it provides a record of permission strategies and needs and can be used during maintenance and trouble-shooting.

Adding New Users

When a new user needs to be added to PPM Pro:

  1. Identify the new user's permission needs. Refer to and update your permissions inventory from Step 1 if you are still using it.
  2. Ensure the new user has a relevant user type (Step 2) given their needed permissions.
  3. If you are using legacy entities (Enterprises/Accounts, Divisions/Business Units, or Departments/Programs), configure relevant legacy entity team permissions (Step 3).
  4. Add the user to relevant groups and make sure the user is in the appropriate unit (Step 4).
  5. Add the user to relevant standard groups (Step 5).
  6. If there is an existing user in your inventory who has the same permission needs and you noted what permission profiles applied within your inventory, for that existing user's permission profiles look at their rules and ensure that the new user is picked up by at least one rule on each profile. If you did not note which permission profiles applied to the user sets in your inventory or if you do not have an inventory, but you do know of an existing user that has the same permissions, you can use the Permissions Explorer to see what profiles the existing user has and then review and update each profile for the new user. If you don't have any of this helpful info, go through your existing permission profiles and add the new user as appropriate to relevant profiles (Step 6).
  7. If any of the profiles had applicable team rules, you'll want to add the user to the relevant entity teams with that profile.
  8. If any of the profiles had applicable unit manager rules, you'll want to make sure the user is a unit manager on the correct unit.
  9. If any of the profiles had applicable special access rules, you'll want to to make sure the user is added as a special access member on relevant organization hierarchy units.
  10. Consider if you need to communicate

Changing User Permissions

If a user has changed roles or needs a reduced or expanded set of permissions:

  1. Identify the needed permission changes. Refer to and update your permissions inventory from Step 1 if you are still using it, being careful to note which permissions are being added and taken away, which might put the user in a different user set(s).
  2. Determine if the user type needs to be changed given these permissions (Step 2).
  3. If you are using legacy entities (Enterprises/Accounts, Divisions/Business Units, or Departments/Programs), remove or add relevant legacy entity team permissions (Step 3).
  4. Review your groups and units to make sure the user is correctly represented (Step 4).
  5. Review your standard groups to make sure the user is correctly represented (Step 5).
  6. If you noted what permission profiles applied within your inventory, for that existing user's permission profiles look at their rules and adjust as needed. Add or remove Global rules relating to the user, but for all other rules you will likely need to leave the rules (so you do not inadvertently remove permissions for other users). Instead you will need to adjust aspects of that user, such as removing/adding/changing the profile for them from/to entity teams (and leaving/adding the team rule to the profile), making sure they are/not an owner of an entity (leaving/adding the owner rule), are/not a unit manager (leaving/adding the Unit Manager rule), or are/not a special access member on the organization hierarchy (leaving/adding the Special Access rule). If you did not note which permission profiles applied to the user sets in your inventory, you can use the Permissions Explorer to see what profiles the existing user has (as well as what entities in the case of team rules), and then review and update as needed.
  7. NOTE: If the user is still expecting to have the same access as before, particularly if you have removed one or more permissions, you will need to be prepared to handle user questions around why they can no longer access what they used to and/or proactively notify your user that permissions are being adjusted (with a good explanation of why).

Removing User Access

If you need to remove a user from having any permissions in the system, the best approach is to simply deactivate the user. This allows the user to still exist as a resource in the system for staffing, resource planning, and so forth. When a resource is terminated, the corresponding user will automatically be made inactive if the termination date is today or earlier. If the termination date is in the future, you will have to manually deactivate the user. However, the user will no longer be able to log into the system once the termination date has arrived, even if the user is still marked Active.

Removing Profiles

If you determine that there is a profile that is no longer relevant or needed, you can choose to delete it. Deleting it removes its permissions from all users to whom the permissions used to apply, so make sure this is not going to cause any difficulties. Another somewhat safer approach that will keep the profile around (just in case) is to first make all the profile's rules inactive and then after some time has passed (and no users have complained), then delete the profile altogether.

Trouble-Shooting

There are various PPM Pro capabilities and general knowledge that will help you when you need to trouble-shoot why a user does or does not have access to an entity, function, or view.

Implicit Permissions

Once you have granted relevant permissions to your users, they may have implicit permissions for certain situations. There is nothing you need to do to maintain these, they just are capabilities to be aware of so that you do not spend time struggling to understand why a user has one or more of these when trouble-shooting user permissions.

  • User who owns a project - can view and edit the project Details section
  • User who owns a task - can view task details and can edit all task details fields except those that directly affect other tasks or the parent project (Start Date, Target Date, Duration, Manually Scheduled?, Active?, Constraint Type, Predecessor, Successor, Scheduled Resources)
  • User who is scheduled to a task - can view task details
  • User who owns other entities - can view and edit entity details
  • User assigned to an issue - can view and edit issue details
  • Users in general - can view their own availability (for example, within Home > Resources, they can see their utilization and allocations)
  • (New requests feature) Requester and request creator - for their requests:
    • view, edit and submit
    • view after submission, including subsequent gate details, but excluding notes, attachments, and scores
    • place on hold and back in progress
  • (New requests feature) Request approver - for requests for which they are a relevant approver:
    • view, edit, and score
    • approve, reject, or send back to a prior gate (if that capability is configured for the request category)
    • place on hold or place or place back in progress

Confidential Projects

When the Confidential Project field is enabled for a project (usually within Project Settings), access to that project is automatically limited to only authorized users. So one thing to check if a user is asking you to trouble-shoot why they cannot view a specific project is whether or not it is a confidential project. Authorized users include: project owner, project team members, and members of the Admin standard group.

Permissions Explorer

The permissions explorer is a feature that allows you to see who has permissions on a given entity, or, what entities does a user have permission on and how/by what profile. This only applies to entities that are represented in the profile Permission Hierarchy tree: projects, tasks, issues, portfolios, assets, reports, filters, dashboards, organization finance settings, organization internal rates, and new requests. Using the permissions explorer you can answer questions such as:

  • Why does Sarah have the ability to edit my project?
  • Why can Joe create dashboards?
  • Who has access to all of our IT projects?

Not only can these questions (and many others) be answered, but you can also open a relevant permission profile so that you can make adjustments as needed (again, keeping in mind the consequences to other users given Team, Unit Manager, and Special Access rules). See the Permissions Explorer Overview and Using the Permissions Explorer for more details.

Reporting on Permissions

If you are an administrator and would like to simply view a list of either which entities are accessible to a specific user, or, which users can access specific entities, then you can create and run reports to do so. See Reporting on Permissions for more details.