Guide: Permissions - Best Practice

Introduction

Every Council staff member is likely to use the Firmstep platform at some point. For example:

• creating online forms
• submitting employment information or requests (internal forms/processes)
• inputting customer services information/handling cases as back office staff

In order to safeguard data held by a Council, the type and level of individual users’ involvement will be determined in the Permissions Manager. 

Below we describe the actions that are suggested as best practice to manage and maintain the Firmstep user accounts and the Firmstep processes for which councils are responsible and accountable.  The best practice suggests separating out the permission groups required and using a robust and intuitive naming convention to remove ambiguity.  (Thanks to the team at Nottinghamshire County Council for sharing their best practice)

1. Account Creation: General
2. Account Creation: Permission Editor
3. Temporary or Emergency Accounts
4. Assignment of Access Rights
5. Initial Passwords
6. Password Resets
7. Glossary

1. Account Creation: General

The Firmstep platform uses Windows authentication, via your internal network. Each user’s Firmstep account is automatically created the first time the user logs in.

Note: Internal users with .gov.uk addresses should NOT sign up for Self Accounts with their .gov.uk email address (Testing should be carried out using specific test Self Accounts) 

top of page

2. Account Creation: Permission Editor

The Firmstep platform does not strictly have the concept of Administrator Accounts. 

But for the officers who will be responsible for managing and maintaining user permissions, we recommend that you create a specific permission ‘group’  which contains these users. These users will be referred to as Permission Editors in this article.  Permission Editors are Council users who have access to Permissions Manager. Each department can add new Permission Editors to their respective departmental User Group.  (Also see Permission Integrations)

There maybe situations where maintaining the list of users per group is required to be managed by users who do not have full permission to access the Permission Manager - eg Head of team/department etc.  In fact this following suggested method reduces the need for non system administrators to  access the Permission Manager at all - which makes it more secure and removes the need for these managers to understand the  Permission Manager, and ensures that they cannot accidentally adjust permissions or set incorrect permissions.  Using the Permission Integrations it is possible to create a form which checks which users are assigned to a group - adds new users to a group and removes users from a group.  Using this functionality can empower teams to maintain their own groups of users, ensuring they are up to date, or be included as part of an internal starters and leavers process.

3. Temporary or Emergency Accounts

The Firmstep platform does not provide functionality for temporary or emergency accounts, temporary permission can simply be granted or revoked as and when necessary.

top of page

4. Assignment of Access Rights

Permission Editors can ensure access to data and relevant security is in place to meet GDPR by following the suggested protocol. Permission Editors should note that each user’s Permissions are a sum of all the Permissions granted to the User Groups they belong to. Ie. if a user is in both group A and group B, then their permissions will be a total of all permissions that group A and group B have.  Permissions are also inherited - so if group structure has a Parent Group A, with Child Groups B & C, all users in Group B will inherit permissions of both Groups A & B  (for this reason hierarchical permission groups are not recommended as can lead to confusion).

Under GDPR Users should have the minimum access they require to do their jobs but should not be able to view data that is not relevant to their Council role.

User Groups and Permissions in Firmstep

A user can belong to many User Groups and each User Group can have many Permissions.
Permissions grant access to both the Firmstep platform and Categories of processes.

To simplify the understanding of Permission groups it is helpful to consider them separate by virtue of their functionality, and to maintain each type separately:

• Platform Permissions – access to different elements of the platform
• Category Permissions – access to different forms/processes
• Task Assignment Groups – do not have any Permissions

For ease of navigation it is logical to have the User Groups within Permission Manager organised in order, so that Platform Permissions are at the top, followed by Category Permissions and then Task Assignment Groups. Within each of these groupings, keeping User Groups in alphabetical order will facilitate locating each group, especially where there are a large number of Groups.

top of page
 

Pre-Existing Groups (like All Authenticated Users)

Sites come with pre-existing groups that can be seen when looking in the User Groups section of the Permissions Manager:

• Root: All groups are a child of 'root'. Permissions cannot be given to root and tasks cannot be assigned to root, so the fact that all groups are children of root is irrelevant for permissions or task assignment.

• All Authenticated Users: This group contains every single user who has ever logged in to your system, ever. Therefore you should never give this group permissions and you should never create subgroups from this group.

• Widget API broker user group: This group is deprecated and does nothing.

Platform Permissions - accessing the Platform

Generally certain groups should exist for a specific purpose - i.e to give permissions to a certain product/component. If a user would need access to multiple different parts of the Firmstep platform, they should be added to the relevant different groups. It is good practice to ensure that a user is only granted access to the parts of the platform they require.

In order to provide clarity about which part of the Council the user belongs to and why they have the Permissions they have been given, many Platform Permissions are granted by structured User Groups in a parent/child relationship. The Users will only belong to child User Groups, the parent group itself has no users and is simply to facilitate the logical structure, this ensures there is no confusion created by inherited permissions between parent & child groups.

In terms of user access, children inherit permissions from the parent group. These are indicated as yellow permissions instead of green. Therefore, children of a parent group have the same access levels as the parent group. They can then have even more permissions on top of that, if required.

In terms of task assignment, if you are in a child group you are also in the parent group even if your user doesn't have the parent group ticked. Therefore, you can assign a stage to the parent group and all child groups will be able to fill out the stage.

Example Permission groups (not limited to):

• Permission Editors
• Integration Editors
• Self/Dash Admin
• Service Editors

We have implemented a streamlined way of granting CSA permissions to internal users. This can be done as follows: the customer can make a group in the Active Directory with the name FS-Integrated-CSA-Users, and add users to that group. If any of those users then log into Service, they are automatically also added to the CSA group and thus obtain CSA permissions.

Category Permissions - access to different forms and processes

Permission Editors would be responsible for assigning Users with access to as many Form Categories as they need. A single User Group can be assigned Permissions in as many categories as needed (all if necessary).  All forms/processes are required to be in a category and that category enabled to be accessed on Self/Dash. Also - if a form/process is NOT in a category then the view data will be unrestricted - ie visible to all Form Editors.  Therefore it is important to separate development categories from live form categories.

Category Naming Convention

It is good practice for Permission Editors to ensure that Categories adhere to a strict naming convention, which specifies who is responsible for the process, how the process is published and any access control settings (e.g. whether it is anonymous or if authentication is required). 

For example, you could identify the department/team – platform – access control. For example:

• HR – Dash – Forced Login
• Highways – Self – Optional Login
• ICT Access – Dash – Forced Login
• Parking – Self – Forced Login
• ICT Staff Survey – Dash – Anonymous 

top of page

Form Category Permission User Groups

Firmstep recommend making all Form Category Permission User Groups children of a parent group Form Category Permissions. Then each Form Category Permission Groups can be named to identify the department/team responsible for the process and the level of access they are granted.

The individual Permissions are:

Depending on your local requirements you may only requite two levels of access (though other groups as required can be created): 

• Form Editors
  • All Permissions (listed below), including  Publish, Delete and View Data for related Categories
• Form View Data
  • View Data
  • Allow Access

Permissions are identified by buttons (the green buttons show the functionality to which the users in a particular group have access; the red buttons show the functionality to which the users in that group don’t have access). 

Form Editor Permissions

Form View Data Permissions

The department/team name in the User Group would match the department/team name in the Categories that the User Group would have access to. For example:

• ICT 
  • ICT – Form Editors would have editor access to all Categories whose names start with ICT 
  • ICT – Form View Data  would be able to view data in all Categories that start with ICT
• Ctax 
  • Ctax – Form Editors would have full access to all categories that start with Ctax
• Parking
  • Parking – Form Editors would have editor access to all Categories that start with Parking

A user may need to be added to more than one group to tailor their access and Permissions. 

top of page

Task Assignment Groups

A task assignment group should be designated to allow tasks to be assigned based on the work flow of the process, eg the Management Group to approve a request

We recommend that Task Assignment Groups do not have any Permissions other than Allow access and Case View. However, users within a task group may be added to specific Platform/Category Permission Groups to enable them to do other parts of their work.  No permissions are actually required to be defined within Permission Manager to complete a task, the simple fact that a user/group is assigned within task assignment provides the necessary permission.  Separating each type of permission reduces the risk of users inheriting inappropriate permissions.

The Role of Permission Editors

Permission Editors would be council users who have access to Permissions Manager. They are responsible for setting up Permission Groups that have two main functions, those of managing:

• user access to specific groups (User Permission Group/s)
• task assignment

One logical option is that each relevant department in the council has a user group, and each department could add new Permission Editors to their respective departmental User Group i.e. ICT could add new Permission Editors to the ICT Permission Editors Group, for example. 

Permission Editors are able to see details of all users in the Permission Manager, including their email address and the Permission Groups they belong to. Permissions Manager allows searching by name, email address and group.

Assigning or removing a user to/from a Permission Group (a step-by-step guide)

1. In the Users tab of Permission Manager, search for the user
2. Click ‘Edit’ next to the user’s name
3. Check/uncheck boxes so that the groups the user needs to be a member of have a tick next to them
4. Click ‘Save Changes’

top of page

Deleting users and Permission Groups (a step-by-step guide)

1. In the Users tab of Permission Manager, search for the user
2. Click ‘Edit’ next to the user’s name
3. Click ‘Delete User’
4. Click ‘OK’ in the Confirm Delete User dialogue
5. Click ‘Save Changes’

Users cannot be fully deleted from the platform. Although their name may no longer appear in the Permission Manager, their information will still be held in the database. In the same way, deleting a customer’s Self (public) account in Permission Manager will not delete their customer record in Service.

Deleted Permission Groups will show as being restricted and deleting the group will not update any cases or tasks. The tasks will just show the group ID as there will be no name match, deleting groups should only be done with caution, see below.

Viewing open cases assigned to a deleted group

Permission Editors can view open cases by setting a new View Data Group and then migrating the open cases on Publishing a a new version of the process. They can also reassign the open tasks in the Tasks Manager, but this can only be actioned one case at a time

Viewing closed cases assigned to a deleted group

The case will have to be reassigned before it can be viewed and the Permission Editor will need to contact the Firmstep Support Team, providing details of the specific group and cases, so the case can be re-assigned within the data base (again not wholly practical).

top of page

5. Initial Passwords

Passwords are not required to access Firmstep as the user will already have been authenticated by your internal network. (Therefore change password option does NOT show to for internal user accounts)

6. Password Resets

Users do not need passwords to access Firmstep as they have automatic authentication through their Active Directory account. 
Passwords are required to access Dash and Self. Self Users have the ability to reset their password if necessary   (Staff should NOT use work/.gov.us emails when signing up for Self Accounts).

top of page

 

Further useful reading:

 

 

• Permission Manager

 

• Troubleshooting permission issues

 

• Category Permissions

 

• Using Dashboard and permissions

 

• Task assignment and workflow

 

top of page