Regarding flow Designer SubFlow

karpuram sai di
Tera Contributor

Hi Community,

I recently moved a Subflow from one instance to Another instance via an Update Set. The subflow contains a Microsoft AD Spoke action to "Create Group."

The Issue: While the subflow works perfectly in the Source instance, it hangs at the AD "Create Group" step in the Target instance. The execution remains "In Progress" and never moves to the next path.

The Error: Looking at the logs, I see the following JavaScript Exception:

JavaScriptException: Error: {sys_id_value} is not a valid sys_id of the discovery_status table
The stack trace points to: -
Script Include: "DiscoveryStatusMonitor" -
Method: getDiscoveryStatusRecord -
Trigger: A Business Rule on ecc_queue that tries to process the agent_correlator field

 

What I've Checked:

  1. The AD Connection/Alias is configured and "Connection Successful" in the Target instance.

  2. The MID Server is up and has the necessary AD capabilities.

Can someone help me on this if anyone faced this issue.

Any help would be appreciated!

3 REPLIES 3

ayushraj7012933
Mega Guru

Hi   @karpuram sai di ,

This issue is typically related to ECC Queue processing in the target instance, rather than a problem with the Microsoft AD Spoke action itself.

The error:

“{sys_id_value} is not a valid sys_id of the discovery_status table”

indicates that something is interfering during ECC processing, which is why the Subflow remains in “In Progress” state.

What’s Happening

  • Microsoft AD Spoke actions execute via MID Server → ECC Queue

  • While processing ECC records, a Business Rule is invoking DiscoveryStatusMonitor

  • This script expects a valid record in the discovery_status table

  • An invalid value is being passed, causing a JavaScript exception

  • Due to this failure, the ECC response is not completed → Flow gets stuck

Steps to Resolve

1. Check ECC Queue

  • Navigate to: System Logs → ECC Queue

  • Filter for:

    • State = Processing or Error

  • Identify any stuck records related to your Subflow

2. Review Business Rules on ECC Queue

  • Go to: System Definition → Business Rules

  • Filter:

    • Table = ecc_queue

  • Look for rules referencing:

    • DiscoveryStatusMonitor

    • agent_correlator

3.  Validate Discovery Configuration

  • Ensure Discovery is properly set up in the target instance

  • Check table:

    • discovery_status

  • Confirm valid records exist

4.  Disable or Fix the Business Rule (Key Step)

  • Temporarily disable the identified Business Rule on ecc_queue

  • Re-run the Subflow

This typically resolves the issue if the rule is causing interference

5. Verify MID Server

  • Ensure MID Server is:

    • Up and Validated

    • Has required capabilities (e.g., PowerShell/AD)

  • Test with a simple AD action

6. Re-test the Subflow

  • Re-publish the Subflow

  • Execute again and verify it progresses past the AD step   

     



    If you find my response helpful or it resolves your issue, kindly mark it as Helpful and Accept the Solution.

    This helps others in the community quickly find the correct answer and improves overall knowledge sharing.

    Thank you for your support!

Tanushree Maiti
Tera Sage

Hi @karpuram sai di 

 

It can be caused by a reference to a discovery_status record that does not exist or has been deleted

 Check your script include if somewhere it is looking for the reference which is invalid (empty) and it can't find a record to display.

 

As per this blog, This is a known issue . In that case raise a case to your ServiceNow vendor and look for ETA for the fix.

 

https://www.findbugzero.com/operational-defect-database/vendors/sn/defects/PRB1919668

 

 

 

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:

yashkamde
Mega Sage

Hello @karpuram sai di ,

 

I guess the subflow is trying to reference a sys_id from the source instance that doesn’t exist in the target instance.

Do this : Re‑open the subflow in the target instance and re‑select the AD Spoke action inputs (especially the Connection/Alias and any referenced records).

 

Note : sys_ids are instance‑specific, so you’ll need to re‑map the references in the target environment to valid records there.

 

If my response helped mark as helpful and accept the solution.