Approval workflow stuck at manager level in cloud deployment, queue delay impacting release deadlines

PLM Teamcenter
, , , , , , , ,
1

We’re experiencing workflow blockages in TC 12.4 when approval tasks route through our matrix organization structure. Engineers in our company report to both a functional manager (by discipline) and a project manager (by program), and the workflow-mgm module gets stuck trying to determine the correct approval path.

When a change request is submitted, the workflow should route to the engineer’s functional manager first, then to the project manager. Instead, it creates duplicate tasks for both managers simultaneously, and neither can complete the approval because the workflow is waiting for a single “manager” role that’s ambiguous in our org structure.

List<User> managers = user.getManagers();
// Returns 2 managers, workflow expects 1
if (managers.size() != 1) {
    throw new WorkflowException("Ambiguous manager");
}

This blocks approvals for 40% of our engineering staff who have dual reporting. How do others handle multi-manager approval rules and matrix organization routing logic in workflow configurations?

2

Be careful with parallel approvals from a compliance perspective. For SOX or FDA-regulated changes, you may need to demonstrate which manager approved which aspect. We use sequential routing with explicit scope: functional manager approves technical feasibility, then project manager approves resource allocation. Each approval is scoped to their domain of responsibility, which satisfies auditors better than generic “manager approved” stamps.

3

Your matrix organization workflow requires comprehensive redesign across routing logic, approval rules, step customization, and org hierarchy configuration.

Matrix Organization Routing Logic: Replace the ambiguous manager lookup with role-specific routing:

User functionalMgr = user.getManagerByType("FUNCTIONAL");
User projectMgr = user.getManagerByType("PROJECT");

if (changeRequiresTechnicalApproval(change)) {
    routeToApprover(functionalMgr, "Technical Review");
}
if (changeRequiresResourceApproval(change)) {
    routeToApprover(projectMgr, "Resource Review");
}

Define routing rules in workflow-config.xml:

<routingRule changeType="TECHNICAL">
  <approver role="FunctionalManager" sequence="1"/>
  <approver role="ProjectManager" sequence="2" condition="costImpact > 10000"/>
</routingRule>

This makes routing deterministic based on change attributes, not just org structure.

Multi-Manager Approval Rules: Implement a decision matrix for approval requirements:

Change Type Functional Mgr Project Mgr Approval Mode
Spec Change Required Optional Sequential
Cost Impact Optional Required Sequential
Schedule Impact Required Required Parallel

Configure in your workflow template:

// Pseudocode - Approval routing logic:
1. Evaluate change attributes (type, cost, schedule impact)
2. Determine required approvers based on decision matrix
3. If both required:
   - Technical changes: Sequential (Functional → Project)
   - Schedule changes: Parallel (both simultaneously)
4. Configure join conditions:
   - Sequential: Wait for each in order
   - Parallel: Advance when ALL complete

Workflow Step Customization: Create custom workflow handlers for matrix routing:

public class MatrixRoutingHandler extends EPMHandler {
    public void execute() {
        WorkflowTask task = getCurrentTask();
        User originator = task.getOriginator();

        // Get both managers with explicit role types
        User funcMgr = orgService.getManager(
            originator, OrgRole.FUNCTIONAL);
        User projMgr = orgService.getManager(
            originator, OrgRole.PROJECT);

        // Route based on change characteristics
        if (requiresBothApprovals(task)) {
            createParallelTasks(funcMgr, projMgr);
        } else {
            createSequentialTasks(funcMgr, projMgr);
        }
    }
}

Handle the ambiguous manager exception by making role explicit in every query.

Organization Hierarchy Configuration: Restructure your org model to support matrix relationships:

  1. Define role types in Organization preferences:

    • FUNCTIONAL_MANAGER (discipline-based: Mechanical, Electrical, Software)
    • PROJECT_MANAGER (program-based: Program A, Program B)
    • RESOURCE_MANAGER (administrative)

  2. Assign users to multiple manager relationships:


Engineer: John Smith
  Reports To: Sarah Chen (FUNCTIONAL_MANAGER, Mechanical)
  Reports To: Mike Johnson (PROJECT_MANAGER, Program Alpha)

  1. Configure delegation rules:

    • Functional manager OOO → Delegate to senior engineer in discipline
    • Project manager OOO → Delegate to program lead
    • Never cross-delegate between functional and project roles

  2. Implement escalation paths:

    • If functional manager doesn’t respond in 48hrs → Escalate to department director
    • If project manager doesn’t respond in 24hrs → Escalate to program director

For your 40% blocked approvals, implement this phased fix:

Phase 1 (Immediate): Add workflow step that explicitly asks originator “Which manager should approve: Functional or Project?” This unblocks workflows while you implement the full solution.

Phase 2 (Week 2): Update org model with role types, assign all dual-reporting engineers to both manager types.

Phase 3 (Week 4): Deploy custom routing handlers that evaluate change attributes and route to appropriate manager(s) automatically.

Phase 4 (Week 6): Implement parallel approval capability for changes requiring both functional and project approval.

Validate with test workflows covering all scenarios:

  • Single manager (control case)
  • Dual manager, functional approval only
  • Dual manager, project approval only
  • Dual manager, both required sequentially
  • Dual manager, both required parallel
  • Manager OOO with delegation
  • Manager unassigned (new employee)

This comprehensive approach eliminates the ambiguity causing your workflow blockages and provides clear audit trails for compliance.

4

Creating separate role types makes sense, but how do you handle cases where both managers need to approve? Do you use parallel tasks or sequential? And if one manager is out of office, does the workflow stall waiting for them, or can the other manager approve on their behalf?

5

We solved this by adding routing rules based on context. If the change is technical (component spec change), route to functional manager. If it’s schedule/scope related (ECN with delivery impact), route to project manager. Some changes need both in sequence. You’ll need custom workflow handlers that evaluate the change type and select the appropriate manager. The standard workflow engine can’t handle this logic out of the box.