Sharing Control Fields

Purpose

The ability to share or not share control fields is an important aspect of system functionality. Sharing allows field values to be forced from a parent library control across all local risk controls at risk level, which can provide valuable consistency. Not sharing allows for field values to be updated on local risk controls, showing variation in control performance across the business which can provide valuable insights.

Striking the right balance between shared and non-shared fields is important to determine with each customer. This article explains how to make and adjust that balance.

Important Notes

1. CGR Only administrator access is required to enable control core field sharing via admin. CGR retains this access since this can considerably change behaviour. In controls and library controls in the database.
2. System Administrator access is required to enable this custom field sharing via admin.
3. As a general consideration, the majority of users should not have edit permissions on library controls. Otherwise too many users will be able to make changes that will apply across the organisation as well as to their own control, and this will cause friction.
4. It is important to understand customer requirements in this area. As a general example, most will prefer to not share control effectiveness – allowing this to be rated differently for the local contexts of a control across multiple risks/departments which provides insights on varying control performance. Other fields, such as those that describe the nature of the control (eg Line of Defence) are more likely to be shared, to enforce consistency in the way the control is understood.

Step by Step Guide To Manage Control Field Sharing

Core Fields 

1. Navigate to Admin > Settings > Control Settings. On this page you will see the options to share a number of core fields.
2. When sharing is enabled for a field, it means that the field value in the parent library control will be pushed down to the local risk control at risk level and it will display with a “Lirabry” book icon besides its title on the forms. If the field value is changed, whether in the library control or in any of its local risk controls, the change will apply across all local contexts if the control.
   • For users with no update permissions to library controls, shared fields will not be editable and will generally be greyed-out.
   • For users with update permissions to library controls, shared fields will appear as editable but are still marked with a computer icon to denote sharing. Any edits will show across all other local risk controls, and users will receive a system prompt in this case. The prompt will invite the user to confirm if they wish to change the field value across the organisation and also (if the user has create rights for new library controls) give them the option to create a new control, which in turn will create a new library parent.
3. When sharing is not enabled for a core field, it means that the field is editable in a local risk control and the field value is specific to that risk control – ie it will not affect other contexts of that control in other risks.
4. As long as a user has update permissions for risk controls, they can make changes to the non-shared field.

Custom Fields

1. The system behaviour described above applies to custom fields. However, sharing is managed at the level of the custom types for library control and risk control.
2. Custom fields can be shared with risk controls simply by adding the custom field to the library control custom type. It will then appear on risk controls with a “library” book icon besides the control title on the forms. If a user does not have update permissions for library controls, then just as with core fields the custom fields will display disabled and the field will not be editable and will generally be greyed-out. However, there is no system warning for custom fields (as with shared core fields) that the change will be applied across all risk controls, so caution is required when using custom fields in the library control; where possible, core fields should be used and translated as required.
3. If a custom field is added to the risk control custom type, it will only appear on risk controls and not in the parent library control. The field is editable in a local risk control and the field value is specific to that risk control – ie it will not affect other contexts of that control in other risks.

Figure 1: Risk control editing on a shared 'Owner' field by a user with update rights to the library control parent (generating a warning relating to application of the change across other risk controls) versus risk control editing by a user with no update rights to the library control parent (where the shared 'Owner' field is greyed-out and not editable).

Figure 2: An example benefit of not-sharing – in this case, allowing control effectiveness to be rated differently at risk control level in different risks/departments, providing insights into control performance across the business.