Best Practice to test workflows on AEM as a Cloud | Community
Skip to main content
Best answer by AmitVishwakarma

Hi @darmien ,
I recently supported a migration from AEM 6.5 on-prem to AEMaaCS, so I can definitely relate.

Here are a few best practices that helped us ensure workflow reliability in the cloud environment:

Practical Best Practices to Test Workflows in AEM as a Cloud Service (from real project experience)

 

1. Test Custom Workflow Steps in Isolation (Unit Testing):
We used AemContext from the AEM Mocks library (JUnit5) to simulate workflow steps and test them independently. This helped us quickly catch logic issues before deploying.

2. Run End-to-End Testing on AEM Cloud SDK:
We did full cycle testing using the local AEMaaCS SDK — including custom steps, participant steps, and transitions. It's close enough to the cloud runtime to give confidence before pushing to higher environments.

3. Avoid Runtime Model Creation:
Since AEMaaCS doesn't retain runtime-created workflow models across deployments, we packaged all workflows under /conf and deployed them using Maven. This avoided accidental deletions after code deployments.

4. Use Cloud Manager Logs to Monitor Failures:
After deployment, we actively used AEM's Developer Console and Cloud Manager logs to trace workflow failures. For example, we once caught an intermittent failure in a custom step that was due to permissions in production.

5. Business UAT with Authors:
For one DAM-heavy use case, we created a sandbox workflow model for business users to simulate real approval flows. Their feedback helped us refine participant roles and email templates early.

6. Performance Testing with Batch Ingestion:
During QA, we triggered the workflows on 1000+ assets using pre-packaged content. This helped us spot delays in steps involving metadata updates, and optimize those parts before going live.

7. Error Handling & Logging:
I’d recommend wrapping custom step logic with structured logging and try-catch blocks, so you can catch and handle errors gracefully in production.


Regards,
Amit

2 replies

giuseppebaglio
Level 10
May 8, 2025

hi @darmien, as a general rule of thumb, the best practice is to implement a comprehensive testing suite case:

  • Unit Testing: Write unit tests for individual workflow steps and components to ensure they work as expected.
  • Integration Testing: Test the integration of your workflows with other AEMaaCS services and external systems.
  • Load Testing: Perform load testing to ensure your workflows can handle the expected volume of content and user interactions.
  • User Acceptance Testing (UAT): Conduct UAT with end-users to validate that the workflows meet their requirements and expectations.

You might find helpful information in this adaptTo() talk: Testing patterns with AEMaaCS.

 

DarmienAuthor
May 9, 2025

Thanks for the clarity!!

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity AdvisorAccepted solution
Community Advisor
May 8, 2025

Hi @darmien ,
I recently supported a migration from AEM 6.5 on-prem to AEMaaCS, so I can definitely relate.

Here are a few best practices that helped us ensure workflow reliability in the cloud environment:

Practical Best Practices to Test Workflows in AEM as a Cloud Service (from real project experience)

 

1. Test Custom Workflow Steps in Isolation (Unit Testing):
We used AemContext from the AEM Mocks library (JUnit5) to simulate workflow steps and test them independently. This helped us quickly catch logic issues before deploying.

2. Run End-to-End Testing on AEM Cloud SDK:
We did full cycle testing using the local AEMaaCS SDK — including custom steps, participant steps, and transitions. It's close enough to the cloud runtime to give confidence before pushing to higher environments.

3. Avoid Runtime Model Creation:
Since AEMaaCS doesn't retain runtime-created workflow models across deployments, we packaged all workflows under /conf and deployed them using Maven. This avoided accidental deletions after code deployments.

4. Use Cloud Manager Logs to Monitor Failures:
After deployment, we actively used AEM's Developer Console and Cloud Manager logs to trace workflow failures. For example, we once caught an intermittent failure in a custom step that was due to permissions in production.

5. Business UAT with Authors:
For one DAM-heavy use case, we created a sandbox workflow model for business users to simulate real approval flows. Their feedback helped us refine participant roles and email templates early.

6. Performance Testing with Batch Ingestion:
During QA, we triggered the workflows on 1000+ assets using pre-packaged content. This helped us spot delays in steps involving metadata updates, and optimize those parts before going live.

7. Error Handling & Logging:
I’d recommend wrapping custom step logic with structured logging and try-catch blocks, so you can catch and handle errors gracefully in production.


Regards,
Amit