Configuring Role-based Permissions
- Stacy Reno (Unlicensed)
- Jorge Raya-Navarro
- Cliff Kang (Unlicensed)
- Shirin Sebty (Unlicensed)
In this article:
Permission Filters and Hierarchy of Privileges
New installations of eplansoft REVIEW are pre-configured with permission settings based on best practices.
Users with an 'Administrator' user role have global access (full privileges) to all REVIEW functionality.
For other user roles, making changes to the default settings may be necessary for view, edit, update and delete privileges of projects, documents and versions, plan review assignments and reviewer comments.
The hierarchy of the Permission filters are shown in the diagram, right.
Permission Filter Definitions
Global access
This is the least restrictive permission filter. It provides access to data records not dependent on Project team membership. The Administrator user role is granted global access privileges throughout the application.
Project member
Provides access to Projects based on Project team membership. Users who create new projects are automatically made project team members.
Group member
This filter provides access based on project membership and group membership.
- For users who conduct plan review, the Assignments Page is preconfigured to display unfinished assignments based on project team membership and group membership.
- Individuals in the Group Manager role typically require edit and delete rights to manage comments, stamps and sketches for staff members within their Group(s).
Own(er)
This is the most restrictive permission filter. It provides access to data records created by the individual, personally.
Best Practices
Notify staff members to logout, clear their cache and login again after permission settings have been changed.
User Role Definitions
User roles determine the permissions for an account within EPR. Since permissions are configured at the user role level, all users with the same role will have the same permissions.
Each User Role is pre-configured with default permissions to match the role's typical expected tasks within EPR, but many role permissions can be adjusted by the Admin. The Admin cannot rename the User Role labels, however.
| User Role | Description |
|---|---|
| Admin | The Admin role is tasked with assisting in the initial configuration of the EPR portal. This user can update portal configurations that affect permissions, assignment workflow, email, and even portal branding as needed. The Admin can also manager user accounts within EPR. Some of the most significant Admin abilities include managing:
The Admin role can also perform the functions of every other user role in EPR, including project creation, assignment intake, plan review, and packaging deliverable back to applicants. |
| Project Coordinator | The Project Coordinator is usually reserved for intake staff/permit technicians. The main responsibilities for these users are to:
When all review assignments have been given an approved, rejected, or canceled status, Project Coordinators will be notified so they can prepare a Corrections Report letter with all reviewer feedback and then package files to return to the applicant, either through email or, more commonly, through check-in to an integrated portal. This user role typically cannot perform plan review. |
| Reviewer | The Reviewer (or "plan checker", "plans examiner", etc.) has these main responsibilities:
Reviewers belong to one or more Groups (think of these as Departments or Sub-departments) and are responsible for completing plan review tasks (“assignments”) made for their Group. In some cases, especially for larger agencies, assignments are made for a specific named Reviewer within a Group. Although other users are still able to access the assignment, the named Reviewer is expected to complete the review assignment task. At the end of a review cycle, the reviewer must provide either an approval, rejection, or other status for the assigned plans and, if appropriate, may stamp plans as well. Reviewers can also create Corrections Report letters, if desired. The Reviewer role is not configured to perform intake of plans or prepare deliverable packages to send back to an applicant – for this functionality, see Project Coordinator. The Reviewer role is not configured to perform intake of plans or prepare deliverable packages to send back to an applicant – for this functionality, see Project Coordinator. |
| Group Manager | The Group Manager functions as an elevated ‘Reviewer-type’ role.
A Group Manager cannot edit or delete markups for another Group unless they also belong to the other Group. |
| Project Manager | The Project Manager is the highest level of ‘Reviewer-type’ role.
A Project Manager cannot edit or delete markups for another Project unless they also manage that Project. |
| Contributor | A licensed user who has been granted access to view and respond to comments made by the Reviewers in an existing project.
They cannot respond if response is not enabled, nor can they create new comments or markup plans. This user role cannot perform plan review. |
Contributors are prevented from functioning as Plan Reviewers so they cannot perform markup, but they can access the Review page as of a recent update.
The Contributor Role Explained
The Contributor user role is provided for clients who want to invite external customers, or partners, onto a project team for the purpose of collaborating with the plan reviewers.
Contributors may not conduct reviews. Instead, these individuals can:
- Become members of a project team. This provides the contributor with project access, as shown below (steps 1-3):
- View comments made by plan reviewers for those projects (4), apply filters (5) and check whether any are flagged by reviewers as priority comments (6).
- Respond to comments made by the plan reviewers in a secure, user friendly web page (7-11).
- View the comments on the plans pages through the EPR Review page.
- Download the documents if those privileges have been granted.
While comments are visible to contributors once they become a project team member, the ability to respond to a comment is controlled by the reviewer who creates the comment ("Response Enabled" feature). At any point during the plan review, if a Contributor is granted access to a project then they will be able to view and respond to comments concurrently with the remainder of the review cycle. Comments added by contributors are placed below the most recent version of the reviewer's comment, and if reviewers update their comment then this updated version will display below the contributor's comment to maintain the chronology of the conversation as clear as possible. Contributor project access can be revoked, if desired, by an agency Admin at any time by removing the user from the project team.
NEW! Contributors can now view a comment directly on the EPR Review page to see it in context. From the Project Comments page, the Contributor hovers over the comment text to display the → (right-facing arrow) icon, as show below. Click on this button (→) to navigate to the Review page.
While on the Review page, Contributors can see the comments on the document page and access attachments to comments (if any), but cannot markup or otherwise modify the plans.
Best Practices for Configuring Permissions for Project Access
Choosing whether to use the default permission filter settings that grant users project member access or to grant users Global Access to projects should be determined before go live.
When the permission filters are set Project Team Member, users who open the Projects page will only see records for projects in which they are a project team member as opposed to all projects that may exist globally. In the same manner, users who open the Assignments page will only see open assignment records for projects in which they are a team member, as opposed to open assignments that may exist globally.
Additionally, project and assignment related email notifications configured in the User's record will also be sent based on project membership or Global Access.
Choosing whether to set the permission filters to Global Access or Project Member access is your choice.
Permission Dependencies for Project records
The Project Workflow Process
For project team members who participate in one or more processes described below, their user roles require the appropriate view, add, edit and optionally delete permissions, to the following entities shown below.
Project Team Membership
- When a plan review assignment is given to a specific user, that individual automatically becomes a project member.
- Users who add projects automatically become project members.
- Administrators are automatically granted membership to all projects.
At minimum, all user roles should have view privileges for Project Management.
Best practices
Project Managers, Group Managers, Reviewers and Contributors should have View privileges as project Team Members. This ensures that users can see their 'own projects', but not projects they are not team members of.
Permissions Dependencies for Plan Review
Plan Review Workflow Process
For project team members who conduct plan review or who manage plan review staff, their user roles require, at minimum, View permissions to Project Management.
permissions to the entities shown in the diagram below, right:
Default Permissions for the Review Page
Best practices for project team members who conduct plan review via the Review Page are shown in the screen shot below. Modify the settings as desired.
Note the typical settings for Group Managers and Reviewers.
.
The Contributor user role cannot be granted permission to the Plan Review page. Instead, Contributors may view/download the marked up documents and view/respond to comments for projects they have membership in. Contributors login into a simplified user interface.
Default Permissions for Project Comments
Best practices for team members privileges on the Project Comments Page are shown in the screen shot below. Modify the settings as desired. Note the typical settings for Group Managers and Reviewers and Contributors.
At minimum, permissions to view comment details is required in order to open the Project Comments page.
Default Permissions for Comment Responses
Best practices for team members privileges on the Project Comments Responses Page are shown in the screen shot below.
Modify the settings as desired.
Step-by-step guide
Follow these steps to modify permission settings:
- Select Security/Permissions from the Navigation panel
- Drill into the appropriate module
- Toggle the View, Add, Edit and Delete checkboxes and choose the appropriate filter for the desired User Role(s)
- Click Save (required).
Notify staff members to logout, clear their cache and login again if permission settings have been changed.
Related articles