Skip to Content
Technical Articles

Archiving – How it is designed, how does it work

Hello all,

In this blog I want to explain how we have designed Archiving in C4C (available from 2011, see this Product Information), how it works (not immediately after you active it in the Business Configuration 🙂 ), and why we have done it this way (to prevent the fear of data loss on your side).
Finally I will give you a foresight how it will get more simply in future release.

Let’s start with the activation:

As it is already stated in the Product Information you first need to choose in the Business Configuration for which of the Business Objects you want to switch Archiving on.
We will come later to these retention periods.

Now this has the following consequence:

  • Early morning each day 3 jobs are triggered for Archiving.
  • Each job is working on all activated Business Objects consecutively
  • The first job Move2Archive looks for potential candidates and move the verified ones to the archive, but let the data still persist in the tenant
  • The second job DeleteLocal checks if the residence period if over and removes the local data
  • The last job DeleteFromArchive finally deletes the data also from the archive

This means if you activate Archiving in the afternoon you have to wait until the next morning to see a potential result.

But what are the results?

Now we need to discuss the Retention Periods (they are pretty well explained in the blog mentioned above, but let me repeat):

  • Retention Period Before Archiving: This defines the “age” of the record. How long it was not changed anymore, giving a good estimate that this record is not used any longer.
    Nevertheless, this is no guarantee that this record can be archived. Think of a long running warranty. It will not be changed over years, but still be in effect.
  • Residence Period: During this time the data exists in both worlds, in the local database as well as in the archive. This provides confidence to you that the data can be restored easily (no fear of data loss).
  • Retention Period Before Deletion: Normally defined by legal requirements to keep the data for verification reasons.

So, the Move2Archive job collects all “old” records. These candidates are handed over to some business checks individually defined and implemented by each Business Object. In most cases they check at least for status values like Completed, Closed, …. Of course they can be even more sophisticated.
They are explained in more detail in this separate blog.

The business check returns not only the verified instances, but add also potential archiving relevant dependent objects (RDO) like pricing documents for quotes. Theses RDO can not exist by their own. They need the verified instance as a kind of anchor. Therefore we will collect not only the data of the anchor object but also of the RDO and place them together in the archive file. They will also be deleted together.

Finally we will update the Archiving status of the objects to ArchivingInProcess, so you & we know when the Archiving process has been started.

You will be able to search, find, and display these instances in the regular UI as well as in the Search Archive (Work Center Administrator –> View Archiving).
Some details for the later one:

  • Keep in mind that you need any search criteria (even a asterisk) to trigger the search.
  • You may also filter by object type to narrow down your result list.
  • By clicking on the link the Quick View will open.
    From here you can even navigate to the Thing Inspector.

Before the job DeleteLocal is executed for a given instance a restore would simply require to reset  the Archiving status (in the current release you need to raise an incident; in the coming releases it will be an action 😉 ).
After the execution of the report the data is deleted from the local database and the Search Archive will be the only place where you can find the archived data.
So your result list in the normal UI is no longer cluttered with this old data.
If you feeling save about this you may also reduce the Residence Period so this effects happens earlier.

The DeleteFromArchive will delete the last remains of the record. After this job no restore would be possible. The data is gone.

But, why do we have three retention periods?

Two’s a company, three is a crowd. You need the first one to determine, what is “old” data, whereas the last one is often determined by legal terms.
But what about this Residence Period? It is introduced to give you the possibility to check what are the archived objects? To ensure you, that your data is not gone forever. A kind of smooth introduction to Archiving.

If you feel save about this (and we expect you to feel like that 🙂 ) you can reduce the Residence Period to zero. Thus the data would be sent to the archive and removed at the same day. You will notice the improvements (no cluttering of regular search, …) immediately.


And that is exactly the way we are planning to move ahead: If we get no big complaints now, this Residence Period will disappear in one of the next releases and the jobs Move2Archive and DeleteLocal will be merged to one. It will make Archiving easier to understand and you will get the improvements in your tenant earlier.


You must be Logged on to comment or reply to a post.