We recently updated our DMS versioning configuration to support parallel approval paths for controlled documents. After applying the changes, our approval workflow gets stuck at the second approval step. The workflow status shows ‘In Progress’ but no approval tasks are being generated for the next approvers.
The issue occurs specifically when documents transition from Draft to Under Review status. I’ve verified the workflow status network connections and the approval step linkage appears correct in the configuration. However, the status profile mapping might be causing the blockage.
This is blocking our document release cycle and causing significant delays in getting technical specifications approved. Has anyone encountered similar workflow interruptions after modifying DMS versioning settings?
I believe I’ve found your root cause. The issue is the incomplete status profile mapping after your DMS versioning configuration update. Here’s what’s happening and how to fix it:
Problem Analysis:
Your workflow is stuck because the status profile mapping doesn’t properly link the REVIEW status to the approval step routing. When documents transition from DRAFT to REVIEW, the workflow engine completes the status change but cannot determine the next approval step because the mapping is broken.
Complete Solution:
Verify Status Network Configuration:
Go to transaction CV01N (or your DMS customizing path) and check the status network for your document type. Ensure that the REVIEW status has an active approval determination rule assigned. The status profile must explicitly reference the approval routing table.
Fix Approval Step Linkage:
In table TDWP or through customizing, verify that each status in your versioning rule has a corresponding approval routing entry:
Update Workflow Binding:
Check workflow template in SWDD (transaction). Verify that the container element binding includes:
Document number (binding to &DOCUMENT&)
Version (binding to &VERSION&)
Status profile (binding to &STATUSPROFILE&)
The critical missing piece is usually the status profile binding, which tells the workflow engine how to route approvals.
Regenerate Approval Routing:
After fixing the status profile mapping, run program RSWUWFML2 to regenerate the workflow-status linkages. This ensures the approval routing tables are synchronized with your updated configuration.
Activate Status Profile:
Make sure to activate the status profile in customizing. An inactive status profile will allow status transitions but won’t trigger approval routing.
Test the Fix:
Create a test document and transition it through the workflow. Monitor in transaction SWI1 to verify that approval tasks are now being generated at step 2.
Why This Happened:
When you updated the DMS versioning settings, the system created new status transition rules but didn’t automatically update the approval step linkage in the status profile. This is a known behavior in SAP 2020 - the versioning configuration and approval routing are maintained separately, so changes to one don’t automatically propagate to the other.
The workflow status network shows connections correctly, but the actual approval determination happens through the status profile mapping, which requires explicit configuration. Without this mapping, the workflow engine doesn’t know which organizational roles should receive approval tasks for each status.
After implementing these fixes, your document release cycle should resume normal operation. The key is ensuring that DMS versioning configuration, workflow status network, approval step linkage, and status profile mapping are all synchronized and properly activated.
This draft is based on general SAP PLM 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 before. Check if your approval step sequence numbers are consecutive in the workflow definition. Sometimes when you modify versioning rules, the step linkage gets broken if there’s a gap in the sequence. Also verify that the QA_MANAGER role has proper authorization to receive approval tasks.
Thanks Sarah. I checked the sequence numbers and they’re consecutive (1, 2, 3). The QA_MANAGER role permissions look correct too. I’m wondering if the status profile mapping is the issue. When I look at the workflow monitor, it shows the transition from DRAFT to REVIEW completed, but then nothing happens. No error messages in the logs either.
Check your status network configuration in transaction CMOD or the DMS customizing tables. The status profile needs to explicitly allow the transition and trigger the approval routing. If the status profile doesn’t have the correct approval determination rule linked, the workflow engine won’t know which approval step to activate next. Look at table TDWP for the workflow-status linkages.
Confirmed this resolves the stuck workflow — updating the status network in CV01N and remapping the REVIEW status profile linkage immediately freed our blocked DMS approval routing.
I had a similar problem last year with SAP 2020. The issue was that the approval step linkage wasn’t properly connected to the status profile after we changed the versioning configuration. The workflow would complete the first step but couldn’t determine the next approver because the status mapping was incomplete. You need to ensure that each status in your versioning rule has a corresponding entry in the approval routing table with the correct organizational assignment.
Look at your workflow container elements. Sometimes after DMS config changes, the workflow binding between the document object and the approval task container gets disconnected. You can check this in SWDD by examining the workflow template. Make sure the binding for the document key and version are properly mapped to the task container.
Another thing to verify - check if your approval determination rule is active for the document type. In DMS customizing, there’s a setting that controls whether approval routing should be triggered for specific document types and status combinations. If this got inadvertently changed during your configuration update, it would explain why tasks aren’t being generated.