In Footprints 12 we do not have (yet) a "native" archiving process.
In version 12, all business rules; Time-Based ones included; are executed for all existing tickets in a workspace.
The automated process is only checking for each and every ticket, if it is compliant with the business rule's criteria you have set in place.
If you do this against a handful of tickets, let's say a few hundred, then no problem at all, the system can cope with it.
If you have thousands, tens of thousands, or even hundreds of thousands of tickets in a single workspace, then you start having a performance problem, and sometimes cause delays in other rules to be applied to your tickets...
For time-based ones, this happens every XX minutes (it is recommended not to set below 15 minutes) and takes a really long time.
What are the available solutions ?
1 - We could increase the Application and Database Servers' CPU resources, but this would last for a short period in time, and would require immense resources over the years >>unrealistic.
2 - We could delete tickets from each workspace, but what if we have to keep traces or history of the old ones ? >> Not possible
3 - We could increase the execution time for each time-based business rules, but this is not a good solution at all.
We need to archive the older tickets...
Tickets will remain accessible, but we stop the automation on them.
Step 1 :
First, we need to create an additional status named "archived" to the original workspace.
This will help us identify if the tickets have already been archived, and avoid reapplying the "copy business rule" to the same tickets twice or more times.
We also make use of an additional field (simple text field) in the original ticket, in which we are going to copy the actual ticket number.
Reason for that is because we'll need this reference to the original ticket once we have archived it.
To achieve that we also need a rule which copies the ticket number to the new "copy of ticket number" field:
I made it a time-based rule with a 1 minute frequency for my test, this must not be your case.
You can set it as after save rule, so that this is updated on ticket creation instead.
Then we Need to create a copy of the existing workspace we want to archive tickets from :
Then, when the copy exists, we need to go and remove all existing business rules from each items you have in this new workspace.
Reason for that is because the tickets copied in this new workspace, will not need to have any type of rule being applied to them.
They simply need to exist there as "closed tickets".
Note : The workspace copy process can take SOME time.
In the below example, I have renamed my workspace as "Workspace B archive", edited the "ticket" item, and delete all Business rules :
Publish the workspace once all rules are deleted.
Now I have an Ticket item in this workspace which is strictly identical to the original one. All fields are there on both sides, which is important since I want to copy all content from the original workspace tickets to the archive one.
I create a "copy" business rule" in the original workspace from which I want to archive tickets.
I make it Time-Based and set a very fast and not recommended Frequency for my need, adapt this to yours (daily or monthly is ideal):
As an action, I ask the rule to create a new record in "Workspace B Archive", created above, and I DO NOT select a Quick template : this forces the system to copy absolutely ALL field content from 1 workspace item to the other, including attachments and field history.
For that to happen, we need to have both items absolutely identical, reason why we made a copy of the original workspace at first...
Save and publish this workspace.
We have completed the "copy process". We now need to get rid of the tickets in the original workspace.
Remember, we have set them to a specific status of "archived" now.
We simply need a rule which deletes the tickets when the status is "archived" :
Note: As always, we do not actually delete the data, we simply set a delete date to the tickets in this workspace. This allows us to continue reporting on them, but also gives us the ability to "undelete" if absolutely necessary.