Our sustain management workflow has a critical bottleneck. We configured auto-approval rules for low-risk ECOs (Engineering Change Orders) based on specific attribute criteria, but the rules simply aren’t triggering. ECOs that should auto-approve are sitting in pending status, causing significant delays in our sustaining engineering process.
The rule configuration checks three attributes: Change Impact (Low), Affected Systems (Single), and Compliance Review Required (No). When all three conditions match, the ECO should auto-approve and move to implementation. Instead, these ECOs remain pending indefinitely, requiring manual intervention.
We’ve verified the attribute values are set correctly on the ECOs, and the workflow rule appears active in the admin console. The workflow rule configuration looks correct to us, but something is preventing the evaluation or execution. This is impacting our compliance timelines since sustaining changes need rapid turnaround. Any insights on what might block auto-approval rules from triggering?
First thing to check - are your workflow rules set to evaluate on the correct trigger event? Auto-approval rules need to trigger on status change or attribute modification events. Also verify the rule priority order in your workflow configuration, as higher priority rules might be blocking execution of your auto-approval rule.
Good point about case sensitivity. I’ll check the exact picklist values. The rule is set to trigger on Submit event when ECO enters Pending Approval status. Could there be a timing issue where attributes aren’t fully committed when the rule evaluates?
We encountered similar issues with sustain-mgmt workflows in 9.3.5. Our problem was related to the Compliance Review Required attribute. Even though it was set to No, the compliance-mgmt module was still flagging certain ECOs for review based on affected part categories. This created a conflict where the workflow rule thought it should auto-approve, but the compliance module blocked it. Check if you have any compliance policies that might override your workflow rules.
Yes, timing can definitely be a factor. If users are setting those three attributes during ECO creation but before submission, the values should be committed. However, if attributes are being set by another workflow rule or script, there could be a race condition. Also check your user privileges - the auto-approval rule executes in the context of the workflow, but if the workflow user doesn’t have approval authority, the rule might fail silently.
Your auto-approval rule failure stems from three interrelated issues that need systematic resolution.
1. Workflow Rule Configuration Analysis:
Auto-approval rules in sustain-mgmt workflows require precise configuration. Verify these specific settings:
- Trigger Event: Must be set to “On Submit” or “On Status Change” to Pending Approval, not “On Create”
- Evaluation Timing: Set to “Immediate” rather than “Deferred” to ensure real-time processing
- Rule Priority: Should be priority 1 or 2 (higher priority rules execute first and can block lower ones)
- Action Type: Confirm it’s set to “Auto-Approve” not just “Notify” or “Route”
In Admin Console, navigate to Workflow Settings > Rules > [Your Rule] and verify the Execution Context is set to “System” not “User”. User context can fail if the submitter lacks approval privileges.
2. ECO Attribute Validation Deep Dive:
Attribute matching is extremely literal in Agile 9.3.5. Common validation failures:
-
Exact Value Matching: “Low” ≠ “low” ≠ "Low " (trailing space). Export your picklist values via SQL to see exact stored values:
Check your Page Three configuration for these attributes and verify the API names match your rule criteria exactly.
-
Null vs Empty: If any of your three attributes is null rather than explicitly set, the rule won’t match even if you think it’s set to a default value.
-
Multi-select Attributes: If “Affected Systems” is multi-select, the rule must check for “exactly equals Single” not “contains Single”.
3. Compliance Impact and Module Interaction:
This is likely your primary issue. The compliance-mgmt module in 9.3.5 has an override mechanism that supersedes workflow rules:
-
Even with “Compliance Review Required = No”, the compliance module evaluates ECOs independently based on:
- Affected part categories (Medical, Aerospace, Automotive trigger mandatory reviews)
- Regulatory change flags (FDA, CE, RoHS compliance)
- Customer-specific requirements
-
Check Compliance Settings > Review Policies. Look for policies that force review based on part attributes rather than the ECO’s Compliance Review Required field.
-
The compliance module logs its decisions separately. Check agile-compliance.log for entries like “ECO-12345: Compliance review mandated by policy POLICY_MEDICAL_DEVICES”.
Resolution Steps:
- Temporarily disable compliance policies for testing - create a test ECO and verify auto-approval works
- If it works without compliance, your workflow rule is correct but being overridden
- Modify compliance policies to exempt low-risk ECOs: Add criteria “Change Impact = Low AND Affected Systems = Single” to bypass mandatory review
- Re-enable compliance with the exemption rule in place
Verification Checklist:
- Export workflow rule configuration and compare attribute API names to database values
- Test with a single-attribute rule first (just Change Impact = Low) to isolate which condition is failing
- Review workflow execution logs at DEBUG level for rule evaluation traces
- Check if any PX extensions or Java customizations are interfering with approval routing
The sustain-mgmt workflow is particularly sensitive to compliance module interactions. Your rule configuration is probably correct, but compliance policies are silently blocking execution. Address the compliance policy exemptions first, then fine-tune attribute validation if issues persist.