Data retention
Retention period management
With Data Retention we refer to the process of maintaining records based on a pre-configured, automatic basis. This covers the deletion of conversations after a given amount of time, moving conversations to archive locations, creating backups of the stored media, etc.
The retention period refers to the duration for which a certain conversation needs to be kept after being recorded and must not be deleted. There are 3 main ways to configure this period in Verba, as shown in the sections below. Conversations that have a defined retention time can be configured to be deleted automatically when their period expires.
User-based retention period | Policy-based retention period | Deletion policy | |
|---|---|---|---|
Set when recording is finished | Yes | Yes | No |
Set on supported WORM storages | Yes | Yes | No |
Storage target support | All | All | All |
Recordings protected during the retention period | Yes | Yes | No |
AD sync support | Yes | No | No |
User-level configuration available | Yes | Yes, but complex | Yes, but complex |
Requires retention policy | Yes (Upload, Move) | Yes (Upload, Move) | Yes (Delete) |
The retention period can be increased | Yes | Yes | Yes |
The retention period can be decreased | No | No | Yes |
| Manual delete during the retention period | No | No | Yes |
Deletion is executed by Verba | Yes | Yes | Yes |
Legal hold support | Yes | Yes | Yes |
The system is not able to protect files from system administrators having full access to a specific folder and delete/modify files. If the drive should be physically protected as well, then we recommend using WORM storage instead.
Deletion policies have an additional confirmation window showing the number of affected conversations, which helps ensure that only the intended users are covered by this policy.
Deletion policy based
Separate deletion policies can be configured to periodically delete conversations that are older than the specified value. The setup is very easy, but a misconfiguration can easily lead to the unintended deletion of certain calls.
There is no retention period configured for the conversations stored in the system, so an Administrator is able to delete conversations from the web interface if he has the right to do so.
Separate deletion policies should only be configured when the retention period (Policy- or User-based) cannot be set for some reason.
For configuration information refer to the Delete policy article.
Policy-based retention period
The retention period setting in the upload and move policies allows setting the retention period right after the system compiles the recorded file. This protects the recording from accidental or intentional deletion attempts until the retention period expires.
The retention period is set on the supported WORM storages (for more information, see WORM) and enforced on ANY other storage target by Verba. Customers can use a simple SMB folder on the network and the Verba system will enforce the retention time.
The retention period setting in the upload and move policies should be used whenever possible, as shown in the image below. No separate deletion policies should be used in these cases to enforce retention time.
Once the retention period is over, a hidden background deletion process will delete the conversation, no separate policy configuration is required. The retention period cannot be reduced, it can only be increased by a separate data retention policy.
For configuration information refer to the Move Media policy or Upload policy articles.
User-based retention period
The retention period can be configured on a user level, that can be used to override any policy-based retention configuration. This simplifies configuration in large deployments.
The retention period setting is set on the supported WORM storages (for more information, see WORM) and enforced on ANY other storage target by Verba. Customers can use a simple SMB folder on the network and the Verba system will enforce the retention time.
The retention period setting should be used whenever possible, as shown in the image below. No separate deletion policies should be used in these cases to enforce retention time.
Once the retention period is over, a hidden background deletion process will delete the conversation, no separate policy configuration is required. The retention period cannot be reduced, it can only be increased by a separate data retention policy.
Legal Hold
Verba provides the ability to place conversations on Legal/Litigation Hold, ensuring that no automated policies or even people with sufficient rights can delete these conversations. This option effectively overwrites the configured retention times in the system and can also apply the Legal Hold on conversations stored on supported WORM storages, see Storage and export targets.
For more information refer to the Legal Hold article.
Data retention for advanced data models
For more information on the available data models, see Data models
The advanced data models are based on 2 separate record types: CDR-Only and Media-Only records. These data models are used by multiple integrations (trader voice, Genesys, Microsoft Teams Instant Messaging, etc.) where there is no way to correlate conversation data records to a single media entry or file. In this model, the retention period of the 2 record types is set separately. In most cases, the Media-Only records are automatically linked to the recorded users, the same way as CDR-Only records. However, there are exceptions, where a single Media-Only records can be referenced by multiple CDR-Only entries belonging to different users. This makes defining the retention period of the Media-Only records more difficult which requires further considerations for choosing the right retention period configuration. The following table summarizes the information about the data retention configuration for supported integration using the advanced data model:
| Integrations with Advanced Data Model | Data Retention Configuration |
|---|---|
| BT ITS | Both CDR-Only and Media-Only records can be linked to recorded users by configuring the recorded extensions. The upload policy configuration can be used to set the retention time based on recorded users/traders for both record types. Deletion policies can also be used, but not recommended. |
| BT IP Trade turret based recording | Both CDR-Only and Media-Only records can be linked to recorded users by configuring the recorded extensions. The upload policy configuration can be used to set the retention time based on recorded users/traders for both record types. Deletion policies can also be used, but not recommended. |
| BT IP Trade TPO based recording | CDR-Only records can be linked to recorded users by configuring the recorded extensions, but not all Media-Only records. In the case of open lines, the system only creates a single Media-Only record which is referenced by multiple CDR-Only entries belonging to different users. The recommendation is to set the retention period of these Media-Only records to the highest/longest retention period in the system. This can be achieved by either assigning the TPO lines (recorded extensions in the system) to a technical user which defines the retention period or using upload policy filters to apply the retention period for these Media-Only records. |
| IPC Unigy | Both CDR-Only and Media-Only records can be linked to recorded users by configuring the recorded extensions. The upload policy configuration can be used to set the retention time based on recorded users/traders for both record types. Deletion policies can also be used, but not recommended. |
| Speakerbus | Both CDR-Only and Media-Only records can be linked to recorded users by configuring the recorded extensions. The upload policy configuration can be used to set the retention time based on recorded users/traders for both record types. Deletion policies can also be used, but not recommended. |
| Cloud9 Call Data API | Both CDR-Only and Media-Only records can be linked to recorded users by configuring the recorded extensions. The upload policy configuration can be used to set the retention time based on recorded users/traders for both record types. Deletion policies can also be used, but not recommended. |
| Genesys active recording | CDR-Only records can be linked to recorded users by configuring the recorded extensions, but Media-Only records cannot always be linked to single users. For various call scenarios (multiple recorded agents are on the same conference call), the system creates a single Media-Only record which is referenced by multiple CDR-Only entries belonging to different users. The recommendation is to set the retention period of these Media-Only records to the highest/longest retention period in the system. This can be achieved by either assigning the Genesys directory numbers (recorded extensions in the system) to a technical user which defines the retention period or using upload policy filters to apply the retention period for these Media-Only records. |
| Microsoft Teams Instant Messaging | CDR-Only records can be linked to recorded users by configuring the recorded extensions, but Media-Only records (representing the chat messages for a day for a chat conversation/room) cannot be linked to users. The system automatically applies the retention period configuration on the Media-Only records according to the following priority. The retention period can only be applied through the recorded extension or user configuration. The upload policy cannot be used to set the retention because the system does not generate files on the Recording Servers (except attachments).
|
On deletion, the system does not check if a Media-Only record has CDR-Only records referencing it or not. It will delete the Media-Only records according to the defined retention period or deletion policy configuration. It is highly recommended to carefully consider the retention period configuration to ensure that Media-Only records are always retained until all the related CDR-Only records.