Change Request Legacy Workflow domain condition not honored on insert – BR vs workflow timing.

shubham007
Tera Contributor

Hi All,

I’m trying to understand the actual behavior of the “Run after business rules” option in legacy workflows, especially around condition evaluation timing.

Scenario

  • Change Request – Standard workflow

  • Workflow condition uses Domain (e.g., Domain is not XYZ)

  • Domain is set via a Before Business Rule (order < 1000) based on Assignment/Implement Group

Issue

  • At submit time, debugger shows Domain = Global initially, then the BR sets it correctly.

  • Workflow still attaches using the initial domain value, ignoring the updated one.

  • Enabling “Run after business rules” did not change this behavior.

  • Using Account-based conditions works as expected.

Questions

  1. How does “Run after business rules” actually work?

    • Does it impact only workflow execution, or also condition evaluation?

  2. Is this option deprecated or unreliable in newer releases?

  3. Given such timing issues, is it recommended to move from legacy workflows to Enhanced Flows (Flow Designer) for more reliable condition evaluation using final field values?

Looking for platform-recommended best practices.
image (6)-redacted_dot_app.pngimage (5).png
image (6)-redacted_dot_app.png

1 REPLY 1

Matthew_13
Mega Sage

Hi all,

You’re not alone; 🙂 this is just how legacy workflows behave, and the wording on “Run after business rules” is honestly misleading.

In a legacy workflow, the decision to attach the workflow happens very early in the transaction, before all Before Business Rules have finished doing their work. At that point, the workflow evaluates its conditions using whatever values are present right then — in your case, Domain is still Global I see.

The Run after business rules checkbox does not delay condition evaluation. It mainly controls when the workflow activities run, not when ServiceNow decides whether the workflow should attach in the first place. So even though your Before BR sets the Domain correctly, the workflow has already made its attachment decision.

That’s why:

  • Domain-based conditions fail

  • Account-based conditions work (they’re already populated earlier)

This isn’t a bug and it’s not something you can really “fix.” Legacy workflows aren’t deprecated yet, but they’re effectively frozen, and edge cases like this won’t be improved.

Best practice going forward is to move this logic to Flow Designer, where conditions are evaluated after the record is committed and you get the final field values every time. If you have to stay on workflows, the safest approach is to either avoid conditions on fields set by submit-time business rules, or attach the workflow unconditionally and do the check as the first step.

Hope that helps — you’re running into a known platform limitation, not a configuration mistake.

 

@shubham007 - Please mark as Accepted Solution and Thumbs Up if you find Helpful!!