Compliance workflow validation fails after skipping approval step

QMS Qualio
, , , , , , , ,
1

I’ve configured a compliance workflow with conditional approval routing where certain steps can be skipped based on risk level. The workflow design allows users to skip the QA approval step for low-risk compliance items, but when they do, the final validation fails with “Required approval missing” error.

The workflow step configuration shows the QA approval as conditional (not mandatory), yet the validation lifecycle still expects it. I’ve checked the approval step dependencies and they seem correct - the final release step only requires regulatory approval, not QA.

This is blocking our low-risk compliance releases and forcing us to route everything through full approval, which defeats the purpose of our risk-based approach. Any ideas what’s causing the validation to fail?

2

I’ve seen this before. Check if your workflow has any parallel approval paths that converge later. Even if one path is marked as conditional, the validation engine might be checking for completion of all possible approval steps rather than just the active path. You may need to adjust the conditional validation rules to explicitly exclude skipped steps.

3

The issue is likely in your transition conditions. When you skip an approval step, you need to ensure the transition to the next step includes a condition that accounts for the skipped state. Otherwise, the workflow engine treats the skip as incomplete rather than bypassed. Check your transition rules in the workflow configuration - you might need to add an OR condition that allows progression either when approval is completed OR when the step is explicitly skipped due to risk criteria.

4

Good point about parallel paths. Our workflow does have regulatory and QA approvals running in parallel for high-risk items, but they should be sequential for low-risk. I’ll review the path configuration to see if that’s causing the validation to expect both approvals regardless of the risk level condition.

5

That makes sense. So I need to modify the validation rules at the final release step to check if QA approval was required before validating its completion? How do I reference the risk level attribute in the validation rule configuration?

6

I’ll provide a complete solution that addresses workflow step configuration, conditional validation rules, and approval step dependencies for your risk-based compliance workflow.

Workflow Step Configuration: The root cause is that qual-2022.1 treats conditional approval steps differently than truly optional steps. When you configure the QA approval step as “conditional,” it still registers in the workflow history, and the default validation checks for completion of all registered steps. You need to reconfigure the step using explicit conditional routing rather than marking it as conditional.

In your workflow design, set up the routing like this:

  • After regulatory review step, add a decision gateway
  • Decision condition: IF compliance_item.risk_level = ‘high’ THEN route to QA_approval_step ELSE route directly to final_release_step
  • This ensures low-risk items never enter the QA approval step, so it won’t appear in workflow history

Conditional Validation Rules: At your final release step, modify the validation configuration to use conditional logic. Navigate to Admin > Compliance > Workflows > [Your Workflow] > Release Step > Validation Rules. Replace the current approval validation with:


// Pseudocode - Conditional approval validation:
1. Check if compliance_item.risk_level equals 'high'
2. IF high risk: Validate that approval_qa_status = 'approved' AND approval_regulatory_status = 'approved'
3. IF low/medium risk: Validate only approval_regulatory_status = 'approved'
4. Return validation result with specific error message if failed

This ensures validation only checks for QA approval when the risk level actually required that step.

Approval Step Dependencies: The issue with your current configuration is that approval step dependencies are defined at the step level, but they don’t account for conditional routing. You need to move the dependency logic to the transition level instead.

For each transition leading to the final release step:

  1. Transition from QA approval (high-risk path): Require approval_qa_status = ‘approved’
  2. Transition from regulatory approval (low-risk path): Only require approval_regulatory_status = ‘approved’
  3. Remove the global dependency that requires all approval steps

Validation Lifecycle Configuration: The final piece is updating your validation lifecycle rules. In Admin > System Settings > Validation Configuration, locate the compliance record validation rules. Add a new rule specifically for approval validation:

Rule Name: Risk-Based Approval Validation

Trigger: On transition to Released state

Condition: Apply conditional logic based on risk_level attribute

Validation Logic: Check only the approvals required for the actual workflow path taken

Testing Your Configuration: After making these changes, test with both high-risk and low-risk compliance items:

  1. High-risk item should route through both regulatory and QA approval, with validation requiring both
  2. Low-risk item should bypass QA approval entirely, with validation only checking regulatory approval
  3. Verify the workflow history shows only the steps actually traversed
  4. Confirm validation error messages are specific about which approval is missing

This approach eliminates the validation failure for skipped steps because those steps never enter the workflow history. The conditional validation rules ensure you’re only validating approvals that were actually required based on the risk level, maintaining your risk-based approach while satisfying the validation engine’s requirements.

7

Exactly right. In the release step validation configuration, you’ll need to add a conditional validator that checks the risk_level field value before requiring QA approval completion. The syntax depends on your version, but generally you’d use something like: IF risk_level = ‘high’ THEN require approval_qa_complete = true.

8

I ran into this exact scenario in qual-2022.1. The problem is that conditional approval steps still create a workflow history entry, and the validation engine checks the history for approval completion regardless of whether the step was required. You need to configure the validation rules at the release step to use conditional logic that matches your risk-based routing.