Search

What is the difference between dormant incidents, archived incidents, and purge delete incidents settings?

Environment:

Archiving, Dormant, Purging 
Oracle B2C Service, all versions

Resolution:

Dormant Incidents

Dormant incidents are not the same as archived incidents.  Dormant incidents are regular service incidents that go dormant.  The configuration DORMANT_INCIDENTS represents the number of days after an incident is in a solved state until agedatabase will put it in a dormant status.  By default, this configuration is set to 0 which is disabled.  This configuration runs off of the incidents.closed date to determine when it should set the incident to dormant.  When an incident becomes dormant, the incidents.dormant and phrases.dormant fields get set to true.  What this means is that when you search for that incident via the console, it won't show up in your search results.  An update to a dormant incident makes it become un-dormant. The path to edit this setting is: Configuration > Site Configuration > Configuration Settings > search by Key.

Archived Incidents 

Archived incidents are incidents that have been removed from your database and are no longer editable.  Archived incident information is read-only and cannot be updated. In addition, you must perform a search to display archived incidents and they can only be viewed through the Open the Archived Incidents component.

Until the 18B release, archived incidents are represented by the following configuration setting:

ARCHIVE_INCIDENTS
Specifies the number of days after which solved incidents will be archived. Set this value to 0 or to a value greater than PURGE_DELETE_INCIDENTS to disable this feature. Default is 365 (1 year).

This value represents the amount of days after the incidents.closed date until an incident becomes qualified to be archived by the agedatabase utility.  

Beginning in the August 2012 release until 18B, the ARCHIVE_INCIDENTS configuration setting was made visible to the Configuration Editor.  You can edit the configuration setting by going to Configuration > Site Configuration > Configuration Settings > and search by Key.

For sites older than August 2012, in order to enable archiving on an interface, you must provide the Technical Support team the number of days after an incident is solved that you would like to set for it to be archived by submitting an incident to Ask Technical Support. We will update this configuration for you as well as turn on the archiving automated process.  Keep in mind that when you set this configuration, the timeframe becomes a sliding window.  

Beginning from 18B release, the archive incidents configuration is moved to Data Lifecycle Policies component in Browser Agent where customers can configure the days after which solved incidents are archived.

The configuration is site specific and not interface specific. Refer to the user documentation here. 

Note:

• An incident must be in a solved state to be archived which then writes the incidents.closed date used by agedatabase.
• Once an incident is archived, it cannot be undone.

Archived incidents can also be purged if needed.  The PURGE_ARCHIVED_INCIDENTS setting specifies when archived incidents will be deleted from the archive.  For more information, see 'Archiving incidents automatically' in online documentation.

Purge Delete Incidents

Prior to the 18B release, PURGE_DELETE_INCIDENTS represents the number of days after an incident is solved that it is permanently deleted from the database. This configuration is set to zero (0) by default which will never be deleted from the database. This setting can be edited at Configuration > Site Configuration > Configuration Settings > search by Key.

Beginning with the 18B release, the incident purge functionality has been moved to the Data Lifecycle Policy in the Browser Agent where customers can view, enable and configure data lifecycle settings.  Refer to the user documentation here.   Data Lifecycle Policy honors relationships of custom objects. Objects that have an aggregation relationship will be deleted when the parent object relationship is deleted. 

Note:  Keep in mind that this is irreversible!  Once an incident is deleted, it cannot be retrieved.

Handling of File Attachments

File attachments are stored in a separate location from incident records. They are accessed via links. The table below describes the status of file attachments and whether file attachments are accessible.

NOTE:

Each of the settings above works based on the incidents.closed setting and the incident being in a solved state.  Since they all work off of this field, there can be some unintended overlap.  

For example, if you set the incident purge period less than the archive incident period or DORMANT_INCIDENTS setting, this will cause incidents to be deleted and never hit the other settings.  The same is true of any of these combinations.  If archive incidents period is set less than DORMANT_INCIDENTS or purge incidents period, this will cause incidents to be archived and never hit the other settings.

Also note that purging of incidents only works off incidents within the database. Because archived incidents are removed and placed into the archive console, they are no longer part of the database and therefore, this setting does not apply to archived incidents.  However, if you wish to purge archived incidents, you can enable the PURGE_ARCHIVED_INCIDENTS setting.

Most organizations will never purge incidents and will set the DORMANT_INCIDENTS to a smaller value than archive incidents period so an incident will go dormant before it is eventually archived.  The equation that can be used to represent whether any of these configurations (assuming they are turned on) will become candidates is the following:
CANDIDATE = [incident in solved state] + [incidents.closed < (Today's date - configuration)].