If you are setting up your account for the first time, you should start by making the following considerations:
The basis of documentation access is built on three pillars: Organisational Units, User Groups, and Roles.
An Organisational Unit (OU) is defined as a means of grouping records into a collection so they can be managed and shared securely, according to the permissions associated with it. It can be thought of as a folder where records can be stored and which only users with appropriate permissions can access. Records include policies, procedures, checklists, standards, equipment records, competency records, incident reports, non-conforming events, etc. Access rights (permissions) vary in rank so for example, a user might be able to access a record to view it but not to edit it. OUs can be designed to reflect the departments of an organisation, like Pathology, Microbiology, etc, but they can also be used as repositories of records that are shared by more than one department, say, All Staff Policies or General Admin.
User groups allow establishing specific access permissions to their members. A user group can include any number of individuals and there can be as many user groups as required. Each user group can have different sets of permissions (roles) that only apply in designated OUs. Therefore, a member of a user group might have high level permissions in one OU and none at all in another. In fact, if a user does not have permission via a user group to access an OU, then the OU won’t be visible to them within the iPassport account. This makes the system used by iPassport an excellent way to keep details out of view from those who don’t need to see them. Typical User Groups may include System Administrators, Super Users, Managers, Technical Staff, etc.
Roles are sets of permissions that define the authority a user can have in a given area. Roles are added to user groups but only in connection to specified OUs so members of a given user group can have different roles in different OUs. To accommodate a wide range of organisational structures, iPassport has a comprehensive list of permissions which can be combined in any way. To make life easier, a set of predefined (factory set) roles are available with generic functions that can help set the system up quickly. These roles can later be used as a basis to create new roles, tailored to the structure of the company. Typical examples of our pre-populated system roles include, Policy Editor, SOP Viewer, Competency Assessor, etc.
|Basic Structure in iPassport:||Allows Creating Complex Organisations:|
To create an OU:
Once the OU has been created it is then possible to create groups that can be associated with it.
Ou Contacts are the people (generally administrators with sufficient training) who can help other colleagues in that OU. These names will appear listed under Help > Who Can Help Me, arranged by OU so that larger organisations can offer local support in each department. Only eligible users (those who have the permission, ‘Desktop:Show Users Menu Item’) for that particular OU will appear in the dropdown list where they can be picked.
To add OU Contacts:
To create a User Group:
It is possible to have multiple groups associated with an OU; each user group can have different permissions assigned to it for the same OU. On the other hand and from experience, though it’s possible to have multiple OUs linked to one user group, we strongly recommend that each user group is only associated with one OU to avoid confusion over what permissions a user has.
All users in one user group will share the same permissions, based on the roles they get assigned within a given OU. They can be members of more than one user group so that different responsibilities can be assigned to reflect the structure of the organisation. For example, only some administrators may be responsible for managing personnel so an additional user group can be created for them, rather than giving all administrators that role (Personnel Management Editor).
Users can be added and removed from a user group at any time.
To assign users to a User Group:
You can see what members a Distribution List has by hovering over it - a black pop-up window with its list of names will appear.
To remove users from a user group:
1. Open the user group to the Users tab as described in steps 1 and 2, above
2. Click the delete (trash/bin) icon under Actions on the rows of those to be taken out
At this point, the users will not have access to any OUs from the user group just created. Two more steps are required. First, OUs must be associated with the user group (we recommend only adding one OU to each user group) and then, roles need to be assigned to specify which permissions the members will be granted within that OU.
It is also possible to link user groups to OUs from within the OU records (under Administration > Organisational Units > Search OUs, select the OU and click the Group Roles tab).
The last step to set up a user’s access to certain areas of an OU is to apply roles to their group within that OU. Multiple roles can be added so that all the members of the user group can perform different functions within the designated OU. This is another good reason to keep things simple by only assigning one OU to each user group. If the staff or their functions change over time, it will be easier to maintain the permission setup.
To add roles to an OU within a User Group:
Every OU listed under a User Group should have at least one Role visible in its row to make it accessible by its members:
iPassport comes loaded with predefined (system) Roles to facilitate initial set up. System roles are not editable. In most cases they will be adequate but it is possible to create new roles (which can be based on existing ones) to refine the set of permissions that will be assigned to a user group.
Roles tend to be designed to cover permissions that are specific to a certain area of the system and to provide a certain rank to its users, such as viewer, editor or administrator.
The pool of permissions is classified by sections to search and identify them easily. For example, for controlled documents like policies, the permissions, Policies:View Authorised Policies, Policies:Edit Policies or Policies:Authorise Policies are available.
To create a new role:
You can quickly identify system roles because they can’t be deleted so they’re missing the delete (trash/bin) icon under Actions
To edit a role (only non-system roles can be edited):
Enabled permissions appear on a white background while disabled ones appear on a pink background.