We wanted to use the archive function for the first time and are surprised how little practical the design is. After a little research here in the community it becomes clear that we are not alone. Let me summarize all the flaws here, many individual ideas do not bring the necessary points.
The main RFE is: Give system administrators more control and flexibility to reflect the requirements of the real world!
Archiving conditions are hard-coded in the main form, instead of being policy-configurable (overlays are no configuration)
By default, the archive qualification and the relevant date field are "hard coded" in the form. The current design hides the fact that very different circumstances are represented in one form. A short explanation using the example of Change: There are standard changes for the daily business of uncritical small things and there are complex changes that are subject to the control of supervisory authorities. It does not make sense to treat all changes in the same way and keep them for the same time. There is only one setting for everything and overlays are not a real configuration alternative.
Using the "Submit Date" as a basis for archiving is in many cases quite nonsense. BMC has recognized this and explained it on every page of the documentation. Logical implementations do not need this kind of explanation
BMC has achieved a significantly better implementation in the Recon engine. There filter criteria and rules can be combined in any way. Perfect!
For the best possible flexibility without customization:
RFE 1 - Make it possible to configure more than one policy, with different conditions and rules
RFE 1a - Make it possible to configure the qualification policy based
RFE 1b - Make it possible to configure the qualification field policy based
Deleting/Exporting of old, archived records is based on one "Age in Days" for everything, instead of being policy-configurable
By default, the "Age in Days" field in the AR System Archive Manager console controls which records are moved or deleted. For example, if you type 180 in the Age in Days field, all records that were archived 180 days ago, or longer, are either moved or deleted. There is only one setting for everything.
The current design hides the fact that each document type (policy) can have very different retention periods. Nobody keeps recon job run informationas long as legally binding changes with periods of 5 or even 10 years.
In order to relieve the system of old data stocks in the best possible way:
RFE 2a - Make it possible to export/delete old, archived records after x days policy based
RFE 2b - Make it possible to export/delete old, archived records schedulded
Archiving start time is hard-coded at midnight, instead of being policy-configurable
By default, the Archiving process runs every 24 hours (starting hard coded at midnight) and uses a set of archiving policies to determine when a record is ready to be moved to the archive. It is currently not possible to configure either all archiving, or a specific archive policy to run at a specific time. There is only one setting for everything.
BMC has achieved a significantly better implementationin almost all other job controls (DMT, normalization, reconciliation, ...). There the start times can be configured as desired. Perfect!
RFE 3 - Make it possible to schedule when the archiving runs, ideally policy based.
Archiving tears the information apart, instead of using the still existing connections (added 02/19/2020, almost forgot my own introduction to the subject)
By default, each archive form stands on its own and links between the forms have not been adapted to the archive world This means that links existing in the data cannot be displayed on the user interface. Currently, you have to collect the total information from a large number of forms yourself.
BMC would have had to simply adapt all form names in an archive form and already the archiving would have an even greater added value.
RFE 4 - Make it possible to to look at archived information, without having to know the internal references between forms.