Workflow condition builder fails to save complex logic with multiple AND/OR groups

BPM ServiceNow
, , , , , , ,
1

I’m building an approval workflow for change requests and hitting a wall with the condition builder. When I try to save conditions with nested AND/OR groups (more than 3 levels deep), the workflow editor either strips out the conditions or throws a validation error.

The logic I need:


(Priority = 1 OR Priority = 2) AND
(Risk = High OR (Risk = Medium AND Impact = Critical)) AND
(Assignment group = CAB OR Requested by is in Management group)

The condition builder UI seems to have limitations with this complexity. The approval routing fails because conditions don’t evaluate correctly. I’ve tried restructuring the logic but can’t get it to save properly. Has anyone found a workaround for complex approval conditions, or do I need to use script includes instead?

2

You’re running into the condition builder UI limitations, which is a common issue with complex approval workflows. Here’s a comprehensive solution addressing all three aspects:

Understanding Condition Builder Limitations: The visual condition builder is designed for simple to moderate complexity. It struggles with:

  • More than 2-3 nested levels of AND/OR groups
  • Complex parenthetical groupings
  • Mixed evaluation orders This is by design to keep the UI manageable for most users.

Solution 1: Script Include for Advanced Logic Create a script include to encapsulate your complex logic:

  1. Navigate to System Definition > Script Includes
  2. Create new script include ‘ChangeApprovalEvaluator’
  3. Implement your logic in a reusable function
  4. Call this from a Run Script workflow activity
  5. Set a workflow variable based on the result
  6. Use that simple variable in your approval activity condition

This approach provides:

  • Testable, maintainable code
  • Reusability across multiple workflows
  • Clear audit trail of evaluation logic
  • Easy modification without workflow changes

Solution 2: Workflow Activity Configuration Restructure your workflow:

  1. Add a ‘Run Script’ activity before approval
  2. Script evaluates all your complex conditions
  3. Sets workflow.scratchpad.requiresCABApproval = true/false
  4. Approval activity uses simple condition: workflow.scratchpad.requiresCABApproval = true
  5. Alternative paths based on the evaluation result

Recommended Approach: Combine both solutions:

  • Create a script include with your business logic
  • Add calculated fields for commonly used complex conditions
  • Use workflow variables to store evaluation results
  • Keep approval activity conditions simple (one or two criteria max)

Implementation Example: In your Run Script activity, call the script include and set the workflow variable. Then your approval activity configuration becomes trivial - just check the variable. This pattern scales well and makes troubleshooting much easier since you can test the script include independently.

The key is recognizing that the condition builder is a tool for simple scenarios. Complex business logic belongs in scripts where you have full control and testability.

3

Have you tried flattening your logic? Sometimes you can restructure complex conditions into simpler equivalent forms. For example, instead of nested OR groups, create separate approval paths. It’s more workflow activities, but each one has simple, reliable conditions that the builder can handle.

4

The condition builder is really meant for straightforward conditions. For business logic this complex, you should definitely move to scripted solutions. Create a script include with a method that returns true/false based on your criteria, then call it from a Run Script activity. This also makes it easier to modify the logic later without touching the workflow itself.

5

We had this exact problem with our change approval process. The solution was to add a calculated field on the change request that evaluates to ‘requires_cab_approval’ based on all those conditions. Then the workflow just checks that one field. Keeps the workflow simple and puts the complex logic in a business rule where it’s easier to debug and test. Works great for us.

6

I’ve hit this same issue. The UI has a practical limit of about 2-3 nested levels. Beyond that, it becomes unreliable. You have two options: break it into multiple approval activities with simpler conditions, or use a script include to evaluate the logic. I prefer the script include approach because you can unit test it and reuse the logic across workflows.