Camunda history deletion not working

Dear Camunda guru,

We are running the Camunda app in Springboot, and we need to clean the history in db regularly. I’ve tested various properties setting in the processes.xml, but failed to make it work so far. My latest setting is shown below, can you please help me find the cause? thx.

<process-archive name="My Workflow">
    <process-engine>default</process-engine>
    <properties>
        <property name="isDeleteUponUndeploy">false</property>
        <property name="isScanForProcessDefinitions">true</property>
        <property name="historyTimeToLive">P1D</property>
        <property name="batchOperationHistoryTimeToLive">P1D</property>
        <property name="historyCleanupBatchWindowStartTime">09:00</property>
        <property name="historyCleanupBatchWindowEndTime">23:59</property>
        <property name="historyCleanupStrategy">endTimeBased</property>
    </properties>
</process-archive>

Have you set the processes definitions with a time to live?
The time to live will clean up and instances of a process that has a time to live set.
Take a look at this rest call for more details on how to set the time to live for future instances.

Thanks, Niall. I tried to avoid the inefficient work to set TTL for every individual process because we have too many of them. My original idea after reading the Camunda doc is to use a global config change to solve the issue once for all.

BTW, I also did try the setting of the individual TTL yesterday for some processes, but it didn’t seem to work. I just tried the REST api call a moment ago, and I will wait to see whether it will move the needle or not.

I found the probable cause from the Camunda engine source: the historic TTL has to be non-null for each process in the sql query. It means that one need to set individual TTL for every process before applying any global config TTL. It’s a little unexpected, but I guess I have to bite the bullet to do it one by one for all my processes. No shortcut.

Well it should be pretty easy to automate this as a one-off - you could even create a process that you could deploy and run against your current setup, might be faster. Then ensure any further deployments come with a TTL already defined.