MBOM workflow not updating part status after revision approval in lifecycle-mgmt

PLM Oracle Agile PLM
, , , , , , ,
1

Our manufacturing BOM workflow has a critical issue where part status doesn’t update after revision approval completes. The MBOM workflow executes successfully through all approval steps, and the revision gets approved without errors, but the associated parts remain stuck in their previous status instead of advancing to Released.

We have workflow status mapping configured to automatically update part status from Prototype to Production when the MBOM revision approval completes. The revision approval process itself works fine - approvers can review and approve, and the revision status changes correctly. However, the downstream part status update simply doesn’t happen.

This creates significant confusion on the manufacturing floor because they’re working with parts that show Prototype status but should actually be Production-approved. We’ve checked the workflow configuration multiple times and the status mapping rules appear correct. There are no error messages in the logs, which makes this even harder to troubleshoot. The audit logging shows the revision approval event but no subsequent part status change event. Has anyone experienced workflow status mapping failures where the workflow completes but status updates don’t propagate?

2

I suspect a privilege issue. The workflow executes in the context of a system user, but the part status update requires specific privileges. Check if your workflow user account has the Change Status privilege for the parts in question. Also verify that the parts aren’t locked by another process - if someone has them checked out or another workflow is active on them, the status update will be blocked.

3

Good suggestions. I confirmed the part lifecycle does allow Prototype to Production transitions. I’ll check the workflow user privileges next. The parts shouldn’t be locked - we can manually change their status through the UI, so it’s specifically the automatic workflow status mapping that’s failing.

4

The audit logging gap is telling. If the revision approval is logged but the part status change isn’t, that means the status change action never executed. This points to either a missing workflow step or a failed condition check. Enable verbose workflow logging and watch for any condition evaluations that might be preventing the status update action from triggering. Sometimes there are hidden prerequisites like required attributes or approver counts that block downstream actions.

5

Your MBOM workflow issue stems from incomplete configuration across three critical areas. Here’s the comprehensive solution:

1. Workflow Status Mapping Configuration: Agile PLM doesn’t automatically propagate status changes from MBOM revisions to affected parts. You must configure explicit status mapping:

In Workflow Designer:

  • Navigate to your MBOM revision approval workflow
  • After the final approval node, add a Status Change action node
  • Configure it to target “Affected Items” not just “Current Object”
  • Map the status transition: Source Status = Prototype, Target Status = Production
  • Set execution timing to “After Approval Complete”

In Admin Console:

  • Go to Workflows > Status Mappings
  • Create mapping: Revision Status = Approved → Part Status = Production
  • Set scope to MBOM workflows specifically
  • Enable “Cascade to BOM Components” option

The key mistake is assuming revision approval automatically updates part status. It requires explicit configuration at both the workflow level (action nodes) and the admin level (status mapping rules).

2. Revision Approval Process Deep Dive: Your revision approval completes successfully, but the issue is what happens AFTER approval:

Verify Workflow Sequence:

  • Approval Node → Status Mapping Node → Notification Node
  • The status mapping must be a separate node, not a property of the approval node
  • Check that no conditional branches are bypassing the status mapping node

Check Workflow User Privileges: The workflow executes as the system workflow user. Verify this user has:

  • Change Status privilege for Part class
  • Modify privilege for all affected part subclasses
  • Execute Workflow privilege

Test by temporarily granting admin rights to the workflow user - if status updates start working, you’ve confirmed a privilege issue.

Validate Part Accessibility:

  • Parts must not be checked out during workflow execution
  • No active changes (ECOs) should be in progress on the parts
  • Parts must be in a lifecycle state that allows status transitions

Query to check for locked parts:

SELECT item_number, checked_out_by, lifecycle_state
FROM item WHERE item_number IN (affected_parts)
AND checked_out_by IS NOT NULL;

3. Audit Logging Enhancement: The absence of part status change events in audit logs indicates the action never executed. Enable comprehensive logging:

Application Server Configuration: Add to agile.properties:


log4j.logger.com.agile.pc.workflow=DEBUG
log4j.logger.com.agile.pc.cmserver.workflow.StatusChange=TRACE

Workflow-Specific Logging:

  • Enable workflow execution trace in Admin Console
  • Set retention to 30 days for troubleshooting
  • Monitor agile-workflow.log for status change attempts

Custom Audit Trail: Implement a PX extension to log status change attempts:

public void onRevisionApproved(IRevision rev) {
    logger.info("Revision approved: " + rev.getName());
    for (IPart part : rev.getAffectedParts()) {
        logger.info("Attempting status change for: " + part.getNumber());
        try {
            part.setLifecyclePhase("Production");
            logger.info("Status changed successfully");
        } catch (Exception e) {
            logger.error("Status change failed: " + e.getMessage());
        }
    }
}

This provides detailed visibility into what’s happening (or not happening) during status updates.

Root Cause Analysis: Based on your symptoms (workflow completes, no errors, no status update, no audit entry), the most likely cause is:

  1. Missing workflow node - The status change action simply isn’t in your workflow definition
  2. Failed condition - A hidden prerequisite is preventing the status change node from executing
  3. Timing issue - The status change is attempting before the revision approval fully commits

Immediate Fix:

  1. Open your MBOM workflow in Workflow Designer
  2. Add explicit Status Change action after approval node
  3. Configure it to update affected parts, not just the revision
  4. Test with a single part MBOM first
  5. Monitor logs during test execution

Long-term Solution:

  • Standardize workflow templates with status mapping included
  • Document workflow user privilege requirements
  • Implement automated testing for workflow status propagation
  • Create monitoring dashboard showing parts with status mismatches

The manufacturing confusion you’re experiencing will resolve once the workflow includes explicit status change actions and proper audit logging confirms execution. Your workflow status mapping isn’t failing - it simply isn’t configured to execute.

6

Check if your status mapping is configured at the workflow level or the revision level. MBOM workflows can have status mappings in multiple places, and they might conflict. Also verify that the part lifecycle includes a valid transition from Prototype to Production - if that transition isn’t allowed in the lifecycle definition, the status update will fail silently.