Correct way of purging workflow in AEM ? | Community
Skip to main content
Level 2
February 18, 2026
Solved

Correct way of purging workflow in AEM ?

  • February 18, 2026
  • 1 reply
  • 16 views

I am trying to create configuraion to purge workflows which are older than 100 days for AEM as clouds service.
Documentation -https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/maintenance 

Above link says to create a node under /conf where as the link below asks you to create node under /apps for maintenance window.

Sample configuration - https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-25921#environment 

 

I'm trying to determine the correct way to create a maintenance window. I used the sample configuration and it worked, but after reviewing the documentation for second time, I realized that the maintenance window is supposed to be created under /conf. So what is correct place to keep this configuration?

Best answer by BrianKasingli

It should be in conf, the documentation states it here, https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/maintenance?lang=en#purge_tasks

=========
It Quotes:
Must be done in git. Override the out-of-the-box Maintenance window configuration node under /libs by creating properties under the folder /conf/global/settings/granite/operations/maintenance/granite_weeklygranite_daily or granite_monthly. See the Maintenance Window table below for additional configuration details.

Enable the maintenance task by adding another node under the node above (name it granite_WorkflowPurgeTask) with the appropriate properties. Configure the OSGI properties, see Regular Purging of Workflow Instances.
=========
 

In AEMaaCS, the official documentation clearly states that workflow purge configuration must be created under the /conf directory, and this configuration must be committed to Git and deployed through Cloud Manager. In Cloud Service, you cannot modify /libs, as it is immutable and managed by Adobe.
 

Therefore, when the documentation says to “override the out-of-the-box Maintenance window configuration node under /libs,” it means you should create the corresponding configuration structure under /conf/global/settings/granite/operations/maintenance/ to override the default settings provided by Adobe.


These folders exist conceptually in /libs, but in AEMaaCS you override them by creating the same structure under /conf. Then, to enable workflow purging, you add a child node (for example, granite_WorkflowPurgeTask) under the selected maintenance window node and configure it with the appropriate properties. These properties define how the workflow instances are purged, such as how many days old they must be and which workflow statuses should be targeted.

 

1 reply

BrianKasingli
Community Advisor and Adobe Champion
BrianKasingliCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
February 18, 2026

It should be in conf, the documentation states it here, https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/operations/maintenance?lang=en#purge_tasks

=========
It Quotes:
Must be done in git. Override the out-of-the-box Maintenance window configuration node under /libs by creating properties under the folder /conf/global/settings/granite/operations/maintenance/granite_weeklygranite_daily or granite_monthly. See the Maintenance Window table below for additional configuration details.

Enable the maintenance task by adding another node under the node above (name it granite_WorkflowPurgeTask) with the appropriate properties. Configure the OSGI properties, see Regular Purging of Workflow Instances.
=========
 

In AEMaaCS, the official documentation clearly states that workflow purge configuration must be created under the /conf directory, and this configuration must be committed to Git and deployed through Cloud Manager. In Cloud Service, you cannot modify /libs, as it is immutable and managed by Adobe.
 

Therefore, when the documentation says to “override the out-of-the-box Maintenance window configuration node under /libs,” it means you should create the corresponding configuration structure under /conf/global/settings/granite/operations/maintenance/ to override the default settings provided by Adobe.


These folders exist conceptually in /libs, but in AEMaaCS you override them by creating the same structure under /conf. Then, to enable workflow purging, you add a child node (for example, granite_WorkflowPurgeTask) under the selected maintenance window node and configure it with the appropriate properties. These properties define how the workflow instances are purged, such as how many days old they must be and which workflow statuses should be targeted.

 

vspsAuthor
Level 2
February 20, 2026

Thankyou. I will update my code.
However, I committed the code with the configuration under /apps and it worked—which is strange unless that’s the expected behavior. The only issue I’m seeing on the Workflow Archive screen is that it displays only two workflows, even though the Completed Workflows section shows 193.

 

See completed workflows