We’re experiencing a critical issue with our knowledge base article approval workflow in AEM. Multiple articles submitted for approval are stuck in ‘Pending E’ status and won’t progress to the next stage.
The workflow was working fine until last week when we reorganized our user groups and updated participant mappings. Now articles just sit there indefinitely. I’ve checked the workflow participant mapping configuration and it seems correct, but something is clearly broken.
Our content team has 15+ articles waiting for approval, and this is blocking our Q1 knowledge base refresh. The workflow instance logs show the process starts but then stops at the approval step without any clear error message.
Has anyone encountered similar issues with AEM workflow participant assignments after reorganizing user groups? What should I check to diagnose why the workflow isn’t routing to the correct approvers?
Building on what Raj mentioned - here’s a systematic approach. You have three areas to address based on your situation:
1. AEM Workflow Participant Mapping Resolution:
First, audit your current workflow model. Navigate to Tools > Workflow > Models and open your KB approval workflow. Check the Participant Step and verify the ‘Participant’ field. If it references a group like ‘content-approvers-old’, you need to update this. The key is understanding that AEM resolves participants at runtime, so the group name must exist and be populated.
2. User Group Assignments Verification:
Go to Tools > Security > Groups and verify your reorganized groups. Check that:
The group referenced in your workflow actually exists with the exact name (case-sensitive)
The intended approvers are members of this group
The group has the necessary permissions on the workflow nodes
No duplicate groups exist with similar names that might cause confusion
The ‘Pending E’ status specifically indicates the workflow engine started participant resolution but encountered an error - usually a non-existent or empty group.
3. Workflow Instance Log Analysis:
For diagnostic details, examine the workflow instance logs:
Navigate to Tools > Workflow > Instances
Filter for your stuck workflows (status = RUNNING)
Open each instance and click ‘History’ tab
Look for entries showing ‘ParticipantStepChooser’ or ‘Cannot resolve participant’
Note the exact group name it’s trying to resolve
Resolution Steps:
Create a new workflow model version with corrected participant mappings. For the 15 stuck instances, you’ll need to terminate them through the Workflow Console (you can select multiple and use bulk actions). Then configure your new workflow model as the default and have the content team resubmit the articles.
Prevention Strategy:
Implement a workflow configuration document that maps business roles to technical group names. When reorganizing groups, always check this document first. Consider using workflow variables or OSGi configuration for participant groups rather than hardcoding them in the model - this makes future changes much easier.
The good news is this is fixable without data loss. Once you update the workflow model and restart the instances with the correct participant mappings, your approval process should flow normally. Let me know if you need help with the specific steps to create the new workflow version.
This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this exact behavior before. The ‘Pending E’ status usually indicates the workflow can’t resolve the participant. Check if your user group names in the workflow model match exactly with the reorganized groups - even extra spaces can break it. Also verify the users are actually members of the assigned groups in User Admin.
This is almost certainly a participant mapping issue. When you reorganized the groups, did you update the workflow model’s participant step to reference the new group names? The workflow engine needs exact matches. Also check if the workflow is using dynamic participant assignment - if it’s calling a custom service to determine approvers, that service might still reference old group names. Look in your workflow instance logs for ‘ParticipantStepChooser’ entries to see what it’s trying to resolve.
Thanks for the suggestions. I checked the workflow model and the participant step does reference a group that we renamed. However, I’m not sure how to properly update it without breaking existing workflow instances. Should I create a new workflow version or can I modify the existing one? Also, what’s the best way to restart the stuck instances once the mapping is fixed?
“Confirmed this resolves the stuck workflow — updating the stale ‘content-approvers-old’ group reference in the AEM Participant Step and repopulating the group immediately moved our KB articles out of ‘Pending Editor Review’.”
Don’t modify the active workflow model directly - that can cause unpredictable behavior for running instances. Instead, create a new version of the workflow with the corrected participant mappings. For the stuck instances, you’ll need to terminate them and resubmit the articles. Use the Workflow Console to bulk-terminate stuck instances, then have your content team resubmit. Going forward, document your group-to-workflow mappings to prevent this during future reorganizations. Consider using workflow variables instead of hardcoded group names for more flexibility.
I encountered this last month. The workflow instance logs should show a ‘Cannot resolve participant’ warning if you dig deeper. Check /var/workflow/instances in CRXDE and look at the specific stuck workflow instances. The workItem node will show what participant it’s trying to resolve.