What options are available for removing older incidents from searching without removing them from our site?
Archiving, Dormant, Purging
Oracle Service Cloud, all versions
We have so many incidents that when we search through our incidents, we get too many old incidents returned which makes it difficult to find the record we are looking for.
Oracle RightNow Cloud Service includes two primary features for managing older incidents in your database:
- The Dormant feature allows you to exclude incidents from searching while retaining them in the database.
- The Archiving feature allows you to remove older, resolved incidents from the database (which also aids performance since the size of your database decreases). Archived incidents are converted to an XML file that can be accessed for viewing and reference, but the content for the archived incidents is removed from the database tables.
Click the next to the appropriate heading below to expand that section for viewing.
Over time, as the number of incidents in your database increases, the dormant incident feature allows you to flag older, solved incidents as dormant so that they can be excluded from general searching at the Support Console.
Setting older incidents as dormant allows you to keep the incidents in your site, but allows you to exclude the dormant incidents when searching incidents on the administrative page. This allows you to improve the speed and accuracy when searching for incidents.
Note: By default, dormant incidents are included for searching at the My Stuff - Questions page so that end-users can access their historical incidents for reference.
Attachments to incidents are stored as well, when you open a dormant incident you will have the ability to view the attachment.
The DORMANT_INCIDENTS configuration setting specifies the number of days after which Solved incidents will go dormant by the agedatabase utility. Set this value to 0 (zero) or to a value greater than the incident purge days setting to disable this feature. By default, this feature is set to 0 which means incidents are never flagged as dormant.
To further clarify how the two configuration settings work together, if both are enabled (i.e. DORMANT_INCIDENTS and incident purge), then, setting the dormant value greater than the purge value will be ineffective because closed incidents will be purged before they reach the dormancy date. However, you can use the dormant setting independent of the purge setting (i.e. you can leave the purge setting off).
Path to DORMANT_INCIDENTS setting: Select Configuration from the navigation area > Site Configuration > Configuration Settings > and search by Key.
- The DORMANT_INCIDENTS setting is interface specific and not site specific.
- You can configure and enable incident purging from Data Lifecycle Policies component in Browser Agent.
When an incident is set to dormant, the keywords for that incident are flagged in the phrases table and excluded from searching on the administrative side. If a dormant incident is edited or updated, the dormancy flag is cleared, and the incident is available through phrase searches.
When the dormant feature is utilized, you can specify whether to include dormant incidents in your incident searches based on other characteristics than the phrases in that incident. That is, you can include dormant incidents when searching by reference number, status, or other field information.
You can add the incidents.dormant field as a filter in your incident reports. Set the default for the field to No so that only non-dormant incidents are searched.
When configured this way, by default, only non-dormant incidents will be included in search results. However, since the field is a run-time filter, you can click the Search icon to search for dormant incidents if you wish.
Note: Text searches do not apply for dormant incidents, but other characteristics such as reference number, assigned to, or custom field information can be used to search for dormant incidents.
You have the additional option of archiving older incidents. Archived incidents are actually removed from the database and stored in a separate file.
When an incident is archived, it is no longer searchable in the application, but can still be accessed through the Incident Archive feature.
- Archived Incidents item is only available if incident archiving has been enabled and incidents have been archived. The Archived Incidents item can be added to a staff member's navigation set along with other reports. Refer to Answer ID 7038: How to access and use the archive console for more information.
Important! Archiving incidents is an irreversible process. Once an incident has been archived, the only way to restore it as an active incident in your site is to manually re-create the incident in the console.
To enable incident archiving for August 2012 and releases prior to 18B: The ARCHIVE_INCIDENTS configuration setting specifies the number of days after which solved incidents will be archived.
Starting from 18B, incident archiving conditions and enablement needs to be done from Data Lifecycle Policies component in Browser Agent. Refer to Using Data Lifecycle Policy to purge (or archive) for additional information on steps to get started on Data Lifecycle Management framework.
To disable archiving, set ARCHIVE_INCIDENTS to zero (0) or disable archive incidents Data Lifecycle Policy in Data Lifecycle Policies component in Browser Agent depending on the site release versions.
- Purge Incidents period may conflict with this setting. If Purge Incidents setting is both non-zero (ex 90) and less than the value of archive incidents settings (ex 365), then archive incidents period is effectively ignored and incidents will instead be deleted. Any time archive incidents period is modified, it is advised to also review purge incidents period.
- Enabling incident archiving may cause data to be irretrievably converted to a read-only format and will affect certain standard reports and all custom reports. Please review this setting description and the documentation carefully prior to turning on incident archiving. Verify that the functionality provided by Incident Archiving will be adequate for the solved incidents older than the intended threshold.
Before you can archive incidents, you must determine which incidents you want to archive and configure interface archiving.
The incidents table and threads table are reduced in size when incidents are archived.
When archiving is enabled, the incidents that meet the archiving criteria -- incidents with a solved status type that have been solved for the time period specified are removed from the incidents table. The archived incidents are converted into a flat XML file that is stored on the server.
After the incidents are removed from the incidents table, a row is inserted into the archived_incidents table for each archived incident. This insertion includes a field that contains the path to the flat XML file for that incident. In addition, key information related to the incident is also inserted, including the contact ID value, when the incident was created and closed, the reference number, title, incident ID, interface ID and the date of the last response. Attachments are still available. They still reside on the attachments server and are accessible.
Please note: In order to access file attachments on an archived incident, there is a section on the 'Details' tab. Any file attachments associated to the incident will be at the bottom of the page. You will be able to click the link and the file will open.
For additional information, refer to the 'Archiving Incidents Automatically' section in online documentation for the version your site is currently running. To access Oracle Service Cloud manuals and documentation online, refer to the Documentation for Oracle Service Cloud Products.
For more information, please see Answer ID 4316: Difference between dormant, archived and purge delete incidents settings.