DocumentationExperience Cloud KCS

Custom workflow models revert to default after deployment in AEM as a Cloud Service

Last update: October 20, 2026

This article explains why custom workflow models in Adobe Experience Manager as a Cloud Service revert to their default definitions after deployment and provides steps to ensure customizations persist.

Description description

Environment

  • Adobe Experience Manager as a Cloud Service
  • Custom workflow models deployed through Cloud Manager

Issue/Symptoms

  • After a content-package deployment, custom workflow models initially appear as expected.
  • After a later deployment or environment lifecycle event, the workflow model under /var/workflow/models contains the default definition instead of the intended custom definition.
  • The original content package isn’t available as an editable package in Package Manager after Cloud Manager deployment. Cloud Manager-installed packages appear as converted, frozen cp2fm artifacts.

Cause

This issue is typically caused by the use of broad or incorrect package filters and manual deployment methods. When package filters are not model-specific, or when manual installation is used in production, custom workflow models can be overwritten by default definitions during environment synchronization or lifecycle events. Managing both design-time (/conf) and runtime (/var) workflow model definitions with model-specific filters and deploying through Cloud Manager ensures consistent, automated deployment.

Resolution resolution

Follow the steps below to address the issue:

  1. Review the package’s filter.xml for broad parent-level roots that cover workflow models. Use model-specific filter roots for the workflow models the package owns, rather than a filter that replaces the entire workflow-model tree. Check the design-time model under /conf/global/settings/workflow/models/<model> and the corresponding runtime model under /var/workflow/models/<model> as part of the deployment review.

  2. Use mode="replace" only when the package contains the complete workflow model structure for the exact filter root, including all steps, transitions, properties, and metadata. Note: FileVault replace replaces content covered by the filter root and removes covered repository nodes that aren’t present in the package. Keep the filter root limited to the intended model; don’t use a broad parent root unless the package intentionally owns every model under it.

  3. Keep the design-time workflow model under /conf/global/settings/workflow/models/<model> in the source-controlled project. After deployment, use **Sync** in the Workflow Models console and verify that the runtime model under /var/workflow/models/<model> reflects the custom definition. Include the runtime /var model in the package only if the workflow owner confirms that this deployment approach and the package validator support it for your project.

  4. For repeatable deployment of source-controlled workflow models, commit the package changes and deploy them through the Cloud Manager pipeline. Don’t use a manual Package Manager install as the repeatable deployment method. Package Manager is available for one-off mutable-content operations; that doesn’t make a manual install part of the Cloud Manager source-controlled deployment.

  5. After updating the filters and deployment approach:

    • Increment the package version.
    • Build the complete AEM project and verify that the generated package contains the intended workflow model.
    • Deploy to Development or Stage through Cloud Manager.
    • Verify the model in the Workflow Models console and confirm that the runtime definition remains correct after deployment and after an environment restart or lifecycle event.
    • After validation, promote the deployment to Production through Cloud Manager.
recommendation-more-help
experience-cloud-kcs-help-kbarticles