Access Group Best Practices

Keep the following set of best practice recommendations in mind when designing the access groups structure:

• Design Early - The access groups hierarchy design is a critical process and should happen early in the Accolade implementation. Changing the hierarchy after a large number of users and projects are entered into the system can be a time-consuming process.
• Keep it Simple - Keeping the structure simple makes it easier to assign users and projects correctly and efficiently. It minimizes unintended denials of information, and is easier for other administrators to understand the system.
• Limited Use of Root Access Group - Assign few or no users to the Root access group. Keeping the Root group sparsely populated reduces maintenance in case you decide to redesign the groups structure or to add restricted groups high in the hierarchy.
• Restricted Users - Create a special group for Restricted Team Members and do not add any projects to it. All users must be assigned to at least one access group. Because users still have access to projects to which they are assigned, assign users with the Restricted Team Members role to this access group.
• Idea Project - Create a special group for the initial assignment of all idea projects. Idea Managers can re-assign promising ideas to other groups after the initial evaluation.
• Automate the Access Group Assignment - Create a calculated metric that automates a project's access group classification. Using a metric at the model level allows you to make a project more or less secure based on a metric's value. See Automating Projects Using Metrics in Process Models.
• Restrict Access Group Assignment at the Process Model Level - To help ensure that portfolios and other projects are created in the correct access group, set restrictions on where projects created using a model can exist. Without restrictions, Process Managers and Idea Managers can create and move projects to the access groups that are assigned to their user. With access group restrictions, they can only create and move projects to the access groups that are assigned to their user that are also part of the restricted list.
• Tests and Training - Create a special group for test projects and training new employees. This allows users to learn and experiment in Accolade without mixing practice and training projects in with real, ongoing company projects.
• Project Assignments - Whenever possible, assign users to projects within their access group assignments. Users can still participate in projects outside those access group when assigned on the project. For example, as a Document Reviewer.

Information Security Examples

Consider the following information security examples as you are planning the security framework at your company.

• Using the Restricted Team Member role and the access groups tree, you can set up several different levels of information security in your projects. For example, use the access groups hierarchy to restrict the information in some projects to project members only while making the information from other projects available to everyone.
• Using the Restricted Team Member role to prevent users from seeing any information other than the deliverable and activity pages that they own. They cannot see other projects, other team member assignments in their own projects, or other project information available.
• Assigning Project Team Members and Project Managers to an access group that contains no projects and has no children that contain projects, restricts those users to accessing only the project pages of projects to which they are assigned. They cannot search for any projects or documents. They can see all the deliverables and activities in their own projects, but none in other projects.
• Assigning Project Team Members and Project Managers to an access group that contains their own project but that has no children, allows them to search for documents in their own projects only. They can access deliverables in their own project both through Search and through the Project pages, but they cannot see other projects.
• Creating all access groups as children of the Root access group and assigning Project Team Members and Project Managers only to projects in their own group allows these users to see and search for information in all of the projects in their group but prevents them from seeing any information from projects in any other groups.
• Assigning users to an access group that contains multiple projects or one with children that contain multiple projects, allows the users to search for and access many projects and their documents. These users can access the projects that they can see both through the Project pages and through Search.
• Assigning Process Managers, Executives, and other users who cannot be members of a project to a group that is part way down the access groups tree completely hides project information in the portions of the tree above where they are assigned. For example, a Process Manager assigned in this manner only sees a portion of the total number of projects when viewing projects through the Upcoming Gates page. Making this kind of assignment can cause unexpected problems. For example, a Resource Planner would not see all of the projects that might be pulling resources from one of her pools.
• To give users access to all projects in Accolade, assign them to the Root access group.