Policies for History Records and Process Instances

This guide provides an overview of the DRM scheduling form for history records. For a detailed look at the functionality see Understanding Data Retention Schedules

The first page of the history and process section lets you set up schedules for history records that don't already have them, manage existing schedules, and maintain global schedules.

History Records without Schedules

This list is populated by history records. You'll find an entry for each unique "labela" value that's been written. By convention, a "labela" value is the name of the process or form that created the history record.

• Select a history record from the list and press "Create"

History Records with Schedules

Histories that already have a retention schedule are listed in the "History with retention schedules" section.

From here you can:

• add additional schedules to a record
• edit an existing schedule (global schedules are managed separately)
• remove a schedule
• see an overview of all of the types of history and all of the schedules that have been added to them

You can add multiple schedules to a single record type - perhaps one schedule to delete attachment data, another to delete reporting data and final schedule to delete all data. See "labelc" later in this guide for more information.

Global Schedules

When you are creating a schedule, you can save it as "global" so that it can be reused by other records. You can edit global schedules and see the records that are using them from this screen.

Whether you are creating a new schedule, or managing an existing one, you'll use the same form.

General Settings

Global Schedules

This drop-down lists any global schedules that have been created. You can think of global schedules as a library of predefined schedules you can apply to multiple records. Selecting one from the drop-down fills all of the remaining fields on the form and prevents further editing. Press "Save" to apply the chosen schedule.

Global schedules are managed from the "Maintain Global Schedules" section. Changes made there will update all schedules using the global schedule.

Description

The description is visible in the DRM itself. It lets users know what the schedule does, for example "Delete all histories 3 months old" or "Delete attachments 1 month old".

Notes

This field can hold internal notes with more information about the schedule.

Available Globally

Use this setting to save the schedule as a global schedule. It will be available to use by other types of history record and can be managed from the "Maintain Global Schedules" section.

Date Rules

Deletion Type

The DRM can perform two different types of deletion.

Retention Period

This is the most common type of schedule you'll set up. Records will be deleted after a set time period.

The retention period is set using an ISO 8601 duration. This Wikipedia article has a good description of how the standard works. For example, P3M sets the retention period as three months.

Retention Period Based On

Choose whether your retention period will start counting from the date the history record was created or from when it was last updated.

History records for active workflow process instances are never deleted.

If a history record relates to a terminated process instance (ie the "labelb" value is the business key of a process instance) the retention period is always calculated from the end date of the process instance.

If a history record does not relate to a process instance (either because the history was created by something else, or the process instance has already been deleted), you can choose whether the retention period is based on the created or last updated date of that history.

Specific Deletion Date

Some products have custom tools to calculate the date a record should be deleted. For example, in Bookings you can calculate the deletion date from the point the event took place rather than from the date the booking was made.

The drop-down lists any end points in the goss.DataRetentionManager.calcDeleteDate.custom namespace.

History Rules

Labelc - Which Histories are Deleted?

You can create multiple schedules for a history "labela", deleting different records at different times. There's more information about our standard "labelc" values in the Labelc Histories and Reporting Data article.

This list box includes all of the current "labelc" history records for your chosen history type. You can pick one or more and all of the records will be deleted when the schedule is processed.

Picking {DEFAULT} will perform a default deletion that includes histories that have "labelc" values of null, "notes", "email" or "attachments". Histories with other "labelc" values will remain.

If you want to create a schedule that deletes a specific type of history with a certain "labelc" value, add the value to the text box. This would let you include "labelc" values that haven't yet been written (so won't appear in the main list).

It is not possible to delete "audit" history records.

Only Delete Sealed Histories?

Choose whether the schedule deletes histories that are both historic (sealed) and those still able to be written to (not sealed). In the majority of cases you'll pick "no" so that all relevant history records are deleted.

Data Deletion Rules

User Data Deletion?

Use these radio buttons to set whether histories of this type can be deleted by a user via their My Account page (using the "User Delete Retention Manager" form, see My Account Integration). Only history types that have schedules, and schedules with this field set as "Yes" appear for a user to manage themselves.

Delete Process Data?

This setting controls whether or not the process instance that created the history record should also be deleted.

The "default" deletion end points picked in the advanced settings below have this functionality built into them and are controlled by this setting. If you pick custom end points to do the deletion, check with the person who wrote them whether or not they are able to delete process data.

Using the default end points, the history records for active process instances (and the active instances themselves) are never deleted.

Note that iCM also has a Scheduled Tasks called PurgeProcessInstances that will (by default) delete terminated process instances after a year.

Deletion Processor

These two drop-downs let you pick custom end points to perform the deletion. These may be end points you have written yourself, or product specific end points we have provided, for example for Deleting Case Management Records.

The "Retention" drop-down lists end points in goss.DataRetentionManager.dailySchedule.custom. The end point you pick here will be used to delete data when the schedule runs.

The "User" drop-down lists end points in goss.DataRetentionManager.userDelete.custom. The end point you pick here will be used to delete data if a user deletes data via My Account (see above).

When the DRM is installed a nightly scheduled task is set up. This task calls the goss.DataRetentionManager.dailySchedule.processSchedules end point.

That end point checks all of your schedules and deletes any records that meet your retention policies.

As mentioned earlier:

• History records for active workflow process instances (ie matching "labelb" business keys) are never deleted
• Terminated process instances may be deleted, depending on the settings in your schedule
  • An iCM schedule task also exists that will delete terminated process instances. By default this task deletes any instances older than 365 days. The task is entirely separate to the DRM schedules set here
• You can calculate the retention period for a history record based upon created or last updated date
• Retention periods based upon last updated date will use the end date of the relevant process instance if there is one, if not, they will use the last updated date of the history
  • While the terminated process instance for a history record exists, retention policies are always based on the end date of that process instance
• If the process instance has been indexed by the platform's search engine, it will be removed from there when it is deleted

For a detailed look at the functionality see Understanding Data Retention Schedules