When iPassport roles were designed, regulatory conventions were more based on trust, and they have evolved so that less responsibility is awarded to an end-user and access to information is granted on a 'need-to-know' basis.  Therefore, some of the system roles (especially the 'Global' ones) are historically too 'generous' with permissions, but many customers still use them, so we cannot update them without causing them problems.  It is also for this reason that custom roles cannot be edited.

Fortunately, it's easy to copy custom roles and create new roles to refine the permissions to a very granular level.  This article provides examples and commentary to help you configure roles for the different job functions in your organisation.

Managing Permissions with Custom Roles

This article includes the following topics:

1: Creating custom roles and managing permissions

Creating a new role is easy and the key (in step 3 below) is to base new roles on existing roles which already include most of the permissions required.  In this section we'll create a new role based on the system role 'Policy Editor' and then we will tweak the permissions to prevent policy editors from authorising their own drafts or reverting authorised versions to draft.

To create a new role:

1. Go to Administration > Roles > New Role (or, click the plus sign [+] next to Roles, as a shortcut)
2. Enter a Name for the new role (e.g., 'Policies Editor Restricted')
3. If the new role is based on an existing one, click the field under, Based on Role to expand a dropdown menu of existing roles and choose one (e.g., 'Policies Editor')
4. Optionally, enter a Description (quote which role the new role was based on for future reference)
5. Click Create Role

To edit a role:

1. Open the new role
2. Click the Permissions tab to open the list of permissions
3. Search for the relevant permissions with the aid of the filters available or just scroll to find them
   • Search - helps filter by key words within the permission name, such as "view"
   • Permission Group - helps filter by ‘modules’ within iPassport, such as Personnel Management
     • The option, 'Desktop' brings up permissions which reveal menu items.
   • Filter by Type - helps filter by the area of the permission, which is quoted in its prefix, such as 'Policies'
   • Only Show Enabled Permissions - helps focus on enabled permissions by hiding disabled ones
4. Tick or untick the checkbox under Status to enable or disable a permission.  

In our example, you can set 'Filter by Type' to 'Policies' to bring up and disable the permissions we want to remove - "Policies:Authorise Policies" and "Policies:Revert To Draft".  There is no 'Save' operation to finish and you can edit roles at any time in this manner, but always remember that roles might be used in multiple user groups.

Which Roles to Use?

There are over 40 custom roles in iPassport, most of which are dedicated to specific modules of the system.  It is possible to build user groups with many specific roles, to declare each area where access will be granted.  The system accepts repeated permissions which might be included in two separate roles.

A more comprehensive approach might be to use one role which includes all the permissions of a set of roles so that building user groups only requires adding one bespoke role with all the permissions the user group members will require in a given OU.  This will also speed up the performance of your system.

For example, if our policy editors are also required to edit SOPs and regular Documents, rather than assigning the three roles, 'Document Editor', 'Policies Editor' and 'SOP Editor' to their user group, we can create one role which gathers the permissions of all three.

This is the reasoning behind 'Global' roles and you can create copies of these to suit your requirements:

• 'Global Editor (excluding admin and personnel records)' - editor access to all modules except 'Administration' and 'Personnel Management'
• 'Global Editor (excluding admin)' - editor access to all modules except 'Administration'
• 'Global Viewer (excluding admin and personnel records)' - viewer access to all modules except 'Administration' and 'Personnel Management'
• 'Global Viewer (excluding admin)' - viewer access to all modules except 'Administration'
  
  

2: Permissions for Administrators

The 'Administration' module should be restricted to the few people who manage the iPassport account.  There are some items where it isn't possible to restrict access to only one OU.  For example, if you can view Locations, Organisational Units, User Groups, or Roles, you can see them all.  The permissions for this area are collected in the system role, 'Administration Editor'.

You can set up roles which allow clerical staff to create or inactivate user records, but as part of this process they need to be able to give membership to User Groups, Skilled Groups and Distribution Lists.  Therefore, though these users can be restricted from viewing or editing roles, OUs and user groups, they can grant or remove membership to/from any user group and potentially give someone access to the entire account.

• A more basic role can be created to just allow an assistant to reset passwords, set a user as inactive or as 'read-only', and possibly, to inactivate or reactivate user accounts.
• It is also possible to set up an administrator role for department administrators who need to be able to manage locations, document workflows and cover pages, for example, but not have access to user records, OUs, user groups or roles.

3: Permissions for Supervisors, 'Personnel Management'

The main area of concern in the 'Personnel Management' module is 'Staff Profiles'.  These should only be accessible to staff supervisors/leads/managers, who need to assign and monitor their team's performance.  Staff profiles contain all the iPassport competency records of a person - reading assignments, tests, assessments, training courses and qualifications.  Even if you don't consider this to be private information, a general user might access colleagues' staff records to copy the answers of a test, for example.

Every user has access to their own staff profile (via 'My Profile > View My Staff Profile'), so they don't need permissions to access 'Staff profiles' unless they manage other staff.

The typical permissions for a supervisor can be found in the role, 'Personnel Management Editor'.  When these permissions are applied in one OU, they will only grant access to staff profiles of users with the same 'Home OU'.

4: Permissions for the 'Laboratory Management' area

The 'Laboratory Management' module is largely public in the sense that records in this area are not contained in OUs.  You can simply grant access only to those who manage elements in this area.   For example, a user doesn't need permissions to access distribution lists to be able to select any distribution list when generating a task or in other places where they are used.  The permissions for this area are included in the role, 'Laboratory Management Editor'.

5: Permissions for the 'Competency' area

The 'Competency' module is another place which should only be accessible to staff supervisors/leads/managers.  None of the competency tasks ('Skill Confirmation', 'Competency Test', 'Qualification Confirmation', or 'Training') require special permissions to be completed by the candidate/assignee.  As mentioned above, every user has access to their own staff profile, where they can view their own competencies, so they don't need any competency related permissions which could grant them access in this module.

• The permissions to manage 'Skilled Groups' are prefixed with, 'Skilled Groups' but the permissions prefixed with, 'Skilled Staff' are needed to add/remove members or documents in skilled groups.
• 
  
• The permissions to manage 'Tests' and 'Assessments' are prefixed with, 'Competency'.  
  • You can separate access of those who design the tests and assessments from those who assign them or act as examiners, such that the designers don't need to see who has been assigned any tests or assessments (and whether they have passed or failed), nor do the assigners and examiners need to see the test templates.
  • Tests and assessments can be scoped to specific OUs, so that the templates are not available to users who don't have permission to access them in those OUs.  They can't be assigned either if they are restricted to OUs the assigner can't access.
  • You can assign tests and assessments to any user in the account if you have the permissions, 'Competency:Assign Tests' and 'Competency:Assign Assessments', however, 
  • You can only view assigned tests and assessments of users in OUs (defined by their 'Home OU') where you have the permissions 'Competency:View Tests' and 'Competency:View Assessments'.

• The permissions to manage 'Training Courses' are prefixed with, 'Training Events'.
  • As with tests and assessments, with the permission, 'Training Events:Edit Training Events', a user can invite anyone to a training event.
  • Training events cannot be scoped to a given OU.

• The permissions to manage 'Staff Qualifications' are prefixed with, 'Staff Qualifications'.
  • Like tests and assessments, staff qualifications can be scoped to specific OUs, so they are only available to those who have permission in the declared OUs.
  • When a qualification is scoped to one OU, you can only assign it to users with the same 'Home OU' (but you can use distribution lists to assign it to others).
  • If a staff qualification is not scoped to any OUs, you can assign it to anyone across the account, and you can also view all the staff who have been added.

6: Permissions for the 'Laboratory Records' area

All the records in the 'Laboratory Records' module belong in one OU so their access can be easily controlled through permissions.  The large collection of permissions allows for very granular management but can also make it difficult to select the appropriate ones.

• 'Controlled Documents' have a set of permissions for each type of document (COSHH, Document, Policy, SOP, etc.).  The following articles group them by activity:
  • Creating a New Draft Controlled Document - Part 2 - Permissions & Settings
  • Create, Edit & Publish New Versions of Documents - Part 2 - Permissions & Settings
  • Document Reviews - Part 2 - Permissions & Settings - please also check the 'Settings' section of this article, which includes preferences that override permissions.
• Permissions relating to 'Equipment' are listed in this article:
  • Equipment Management - Part 2 - Permissions
• Permissions relating to 'Materials & Reagents' are listed in this article:
  • Reagents & Materials Management - Part 2 - Permissions

7: Permissions for the 'Quality Management' area

All the records in the 'Quality Management' module (except Checklists) belong in one OU so their access can also be easily controlled through permissions.

Lists of permissions for features in this module can be found in the articles listed below:

• 'Standards': Standards Editor
• 'Internal Audits': Internal Audit Management
• 'Non-compliances': Non-Compliance - Part 2 - Permissions & Settings
• 'Change Control': Change Control - Part 2 - Settings & Permissions

8: Considering 'Document Control' Preferences

As mentioned above, there are preferences in the 'Document Control' area of 'Organisational Unit Preferences' which override permissions.  The article, Document Reviews - Part 2 - Permissions & Settings, provides information about them.

When it is desirable to allow staff from one department to view only some documents from another department, there are two options to consider:

• Document Sharing can be used to make selected documents accessible in another OU.
• If the documents are part of the reading assignments of staff in other departments, the preference 'Allow users with a skilled task to view authorised controlled documents without explicit permissions' can be used to allow viewing only documents assigned through a 'skill confirmation' task.