This article provides information about project team membership.
Assuming the user-role based permissions have been configured to follow best practices for ‘Project Team’ access vs. Global access, users will have visibility to projects when they belong to the project team.
On the Project Detail Team tab, include the appropriate project manager, group managers, reviewers, coordinator, contributors, who:
- Should receive email alerts for project related events, including project workflow changes.
- Have access to Project details, reviewer comments, plan review assignments, conduct document intake and prepare deliverable packages.
NOTE: When plan review assignments are specifically assigned to a named ‘Reviewer’, that user will automatically become a project team member.
Users who create new projects are automatically made members of the project Team.
See Configuring Membership Distributions for instructions on configuring project Membership distributione-PlanREVIEW® (EPR) provides the ability to regulate project visibility and access for users based on their user role. It can further regulate project visibility, access, and notifications based on whether the user is a project team member, if desired, and membership is obtained as explained below.
| Info |
|---|
Project Team Membership simply means the user is listed as part of the project team, as seen within the project’s DETAILS > Team sub-tab, and is therefore associated with the project. |
| Table of Contents | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
User Roles, Permissions, and Project Membership
Permission settings allow an Admin to globally modify behavior for each kind of user role within EPR. By default, a standard EPR implementation will have project “View” permissions set to GLBL - Global Access for most roles. User roles with this setting can view all projects once logged into EPR. (“Add”, “Edit”, and “Delete” rights then regulate what else each user role can do within a project, if anything. Project Coordinators can usually do more at the project level than a Reviewer, for example.)
For many agencies, the defaults are perfectly fine. Others may prefer to restrict which projects are visible to a user, either as a result of preferred business rules or simply to help keep users focused and on task. Typically this alternative involves setting the additional requirement of Project Team Membership, which occurs when changing the Project Management “View” filter to PROJ - Project Member for one or more user roles.
Anyone logging in with one of those user roles, then, will only be able to view projects where they are listed as a project team member within the project DETAILS > Team sub-tab, as shown below.
...
| Info |
|---|
Other permissions can also be restricted to users who are Project Team Members. Refer to Configuring Role-based Permissions for more information about configuring roles and their permissions within EPR. |
...
How Do I Become a Project Member?
There are several ways that a user can become part of a project team, most of which are automatic based on other actions staff may already be performing. Since Administrators can require users to be project team members in order to view/access the project, it’s important to know the five different methods for becoming a project team member:
Method | Automatic or Manual? | Typical User Roles Affected | Notes | |
|---|---|---|---|---|
1 | Create a project directly in EPR. | Automatic | Project Coordinator, Admin, any other role with rights | For most integrated clients, the partner system creates the project instead of any specific staff member. As a result, staff members may need to be added to a project team through another method. |
2 | Make a user the “Assignee” (named user) for a plan review task. This applies to new assignments as well as reassignments. | Automatic | Reviewer, Group Manager | Any user that can be assigned a plan review task can become a project team member this way. |
3 | Select a user within the Project Manager dropdown from the project’s DETAILS > Info sub-tab. This only applies to the first PM selected. | Automatic | Project Manager (only) | This method is specific to the PM role. If no PM is set manually, the first PM user added to a project through another method is listed as the Project Manager. (Additional PMs will not be listed.) |
4 | Add a user to a project team from the project’s DETAILS > Team sub-tab. | Manual | Any | User(s) must be selected manually and are only added to the current project. |
5 | Create an active Automated Membership Distribution that lists every user that should be added to a project team whenever a new project is created with the specified Purpose and Project Type values. | Manual and Automatic | Any | Listed user(s) are automatically added to every new project that has the specified Purpose and Project Type values, but not to projects that already exist. (For existing projects, users must be added via another method.) |
| Info |
|---|
Once a user is a project member, they will be able to see and access a project at any point until either the project is deleted or the user is removed as a team member. |
...
Membership Distributions
If an Agency wants to regulate project access more tightly, consider setting up automated membership distributions.
Related articles
| Filter by label (Content by label) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Page Properties | ||
|---|---|---|
| ||
|