Don’t Get Burned By Your Security Templates

by Welcome to Marquee Insights



If you’ve ever tried to use the built-in security templates in Project Web App, you may have accidentally messed up your security model without realizing it. This problem applies to Project Server 2003-2013 versions.

Security templates are designed as a way to quickly apply or reapply permissions for predefined roles, when creating new groups and categories. However, the out of box implementation can lead to issues if you don’t realize the impact of applying them.


Groups and Categories have what is known as a many to many relationship.  A group can be associated to multiple categories and a category can be associated to multiple groups. The default security model relationships are shown below where blue boxes represent the Groups and orange boxes represent the Categories.


We’ll use Resource Manager as an example of the security template issue. Resource Manager has four relationships out of box by design:

  • My Organization so that they can see all resources and build team on any project
  • My Projects so that they can view any project of which they are part of the project team or own
  • My Resources so they can only see their resources below them in the RBS so that the Resource Manager can add them to a Resource Plan
  • My Direct Report which is reserved for you to customize functionality for the resources directly below the Resource Manager in the RBS The heavy lifting in the security model is at the intersection points between Group and Category. The intersection is where you set the what allowed Project and Resource actions (Group) can be taken on the data returned by the Category. If you’ve seen a “troubled” security model, it’s usually because this nuance was lost on whoever was maintaining the model.



Felix is a Project Server administrator who accidentally changed some category permissions in production on the Resource Manager – My Projects intersection. “No problem”, thinks Felix, “I’ll just reapply the Resource Manager security template and all will be good.”

    Felix then does the following actions.

He goes to PWA Settings under the Gear.


He clicks on Manage Groups under the Security section.


He clicks on the Resource Managers group to edit.


He scrolls down to Categories to access the Category permissions for the group for My Projects.

He selects My Projects in the Category list to show the permissions. At the bottom of the category permissions section, he selects the Resource Manager template and clicks Apply.


All good right? Not exactly.

The Issue

Remember, Resource Manager Group has four category relationships.


However, if you go into Manage Security Templates, there’s only one entry for Resource Manager.


So, which relationship does this security template represent? Was it the right one for Felix to apply? You don’t know without further research.

Suggested Fix For This Situation

If you choose to use Security Templates, I highly recommend doing the following prep work. This recommendation is based on the real world experience of managing two Fortune 250 company implementations and having cleaned up numerous security models for other companies. An hour or two of prep now will prevent tears later on.

Create a new template for group permissions and one for each intersection for the category permissions using this procedure. If you’ve heavily customized your security model, you will need to create a diagram similar to the one I have above first.

The resulting template list for Resource Manager will be as follows.

  • Resource Manager – Group Permissions Only
  • Resource Manager – My Organization
  • Resource Manager – My Projects
  • Resource Manager – My Resources
  • Resource Manager – My Direct Reports
    Now, when Felix applies a security template, he knows exactly which one he is applying to the security relationship.


You can find the default Project Server 2013 group and category permissions at these links for constructing your templates.

5 Responses to “Don’t Get Burned By Your Security Templates”

March 07, 2014 at 5:08 am, Terry Kneeburg said:

Very nice article, Treb!


March 08, 2014 at 11:58 am, Tom Herrington said:

What about the privileges for the status manager? I found that the status manager role is restricted in certain views like the history of status updates and preview updates, even though they have resources on the selected project(s). I don’t want to give them “my organization” privileges.


March 09, 2014 at 3:52 pm, Treb Gatte said:


I’d need to know the specifics of your security model to address your specific concern. What I can tell you is that in the default security model, the Project Manager tool role, which encompasses the Status Manager, has edit rights to the Projects they own and the My Organization category association provides them with the ability to see all resources. This is necessary if you would like the PM to have the ability to assign any enterprise resource to the project plan. Unless you’ve modified the category permissions at the Project Manager/My Organization intersection, they shouldn’t be able to see all projects.

I have an upcoming posts on security in which I’ll delve deeper into Category permissions and why Security Templates are useful and necessary.



March 23, 2014 at 5:51 pm, Simon Newton said:

Not to mention the use of RBS to dynamically assign, and the complexities you encounter in Matrix organisations. Categories are the biggest trap for Project Server Newbies (and not so newbies). I’ll back your comment that all security models must be designed and tested in great detail before applied, this is Critical!


Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.