MCO change order approval routing API fails to route to correct approvers based on part classification

We’re experiencing change order approval routing failures with REST API change order endpoint in Windchill 11.1. The API ignores part classification attributes when determining approval routing rules, causing MCOs to route to incorrect approver groups.

Our business process requires different approval routing based on part classification (mechanical, electrical, software) and risk assessment level. The approval routing rules should map high-risk mechanical parts to senior engineering review, while low-risk electrical parts go to standard approval workflow.

Current API call creates change order but doesn’t apply classification-based routing:


POST /Windchill/servlet/odata/ProdMgmt/ChangeOrders
{
  "Number": "MCO-2024-1234",
  "AffectedParts": ["OID:12345"],
  "Classification": "Mechanical-HighRisk"
}
// Routes to default workflow, ignores classification

We need the API to evaluate part classification, perform risk assessment, and route to appropriate approver group mapping based on these attributes. How can we trigger classification-based approval routing through REST API? What’s the correct approach for approver group mapping with complex routing rules?

Your approval routing issues require comprehensive solution addressing part classification evaluation, risk assessment logic, workflow integration, and approver group mapping:

Part Classification-Based Routing: The problem is that REST API change order creation doesn’t automatically trigger classification-based routing. Standard workflow templates use simple attribute-based routing that can’t handle complex classification logic. Solution requires custom workflow router implementation. Create custom router class extending DefaultRouter:


public class ClassificationRouter
  extends DefaultRouter {
  // Read affected parts classification
  // Calculate aggregated risk level
  // Return appropriate approver group
}

Router evaluates all affected parts, reads classification attributes (mechanical/electrical/software), and determines routing based on highest risk level among affected parts.

Risk Assessment Integration: Implement risk assessment calculation in router logic. Risk level depends on multiple factors: part classification, change type (design/process/documentation), affected quantity, and customer impact. Create risk scoring matrix: mechanical high-risk parts score 8-10, electrical medium-risk score 4-7, software low-risk score 1-3. Router calculates total risk score and routes accordingly: score >8 routes to senior engineering review, score 4-8 routes to standard approval, score <4 routes to expedited approval.

Approval Routing Rules Configuration: Define routing rules in configuration file read by custom router. This allows modifying routing logic without code changes. Example configuration structure:


<RoutingRules>
  <Rule classification="Mechanical"
    risk="High"
    approverGroup="Senior_Engineering"/>
  <Rule classification="Electrical"
    risk="Low"
    approverGroup="Standard_Approvers"/>
</RoutingRules>

Router loads configuration at initialization and applies rules during routing decisions.

Approver Group Mapping Implementation: Approver groups should be dynamically determined based on part classification and organizational structure. Implement approver group resolver that queries organization structure: for mechanical parts, find mechanical engineering manager; for electrical parts, find electrical engineering lead; for cross-discipline changes, include both groups. Use Windchill’s organization API to query group memberships and role assignments. Cache approver group mappings for performance.

REST API Integration Enhancement: Modify change order creation to pass classification and risk metadata. While workflow determines routing, API payload should include routing hints:


POST /Windchill/servlet/odata/ProdMgmt/ChangeOrders
{
  "Number": "MCO-2024-1234",
  "AffectedParts": ["OID:12345"],
  "RoutingContext": {
    "RequiresClassificationRouting": true,
    "OverrideDefaultWorkflow": false
  }
}

After change order creation, explicitly initialize workflow with routing context. This ensures custom router is invoked with proper context.

Workflow Template Configuration: Modify MCO workflow template to invoke custom router at approval routing activity. Configure routing activity to use ClassificationRouter instead of DefaultRouter. Add workflow variables for classification, risk level, and selected approver group. These variables are set by router and available for audit trail. Configure workflow to log routing decisions for compliance tracking.

Testing and Validation: Test routing logic with all classification combinations: mechanical high-risk, electrical medium-risk, software low-risk, and cross-discipline changes. Verify approver group mapping resolves correctly for each scenario. Ensure workflow audit trail captures routing decisions including classification evaluation and risk assessment results. Test error handling when classification attributes are missing or invalid.

This solution provides robust classification-based approval routing that integrates with REST API change order creation while maintaining flexibility for future routing rule changes.


This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

Approval routing rules are typically defined in workflow templates, not controlled by REST API payload. You need to set routing context attributes that workflow expressions can evaluate. Check if your workflow template has variables for classification and risk level.

We use workflow variables passed through API to control routing. In change order creation, set custom attributes that match workflow routing variables. The workflow template evaluates these attributes at routing decision points to determine approver groups. You need to configure workflow template to read classification and risk assessment from change order attributes.

The issue is workflow initialization. When creating change order via REST API, workflow may not be fully initialized before routing occurs. Try using workflow API endpoints to explicitly start workflow after change order creation, passing routing parameters. This ensures classification-based routing rules are evaluated correctly.

Part classification should be read from affected parts, not from change order itself. Your workflow needs to query affected parts, read their classification attributes, aggregate risk assessment across all parts, and determine highest risk level. Then route based on aggregated risk. This requires custom workflow expression or router class.

Approver group mapping with complex rules often requires custom router implementation. Standard workflow routing is limited to simple attribute checks. We implemented custom router class that evaluates part classification, calculates risk scores, and dynamically determines approver groups based on business rules. Router is invoked by workflow template at routing activity.