Policies for History Records and Process Instances

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).