Using setWorkflow(false) doesn't stop Flow Designer flows from executing?

[maynartt]

I'll admit, I didn't yet prove that absolutely nothing else was executing to make this happen, but I strongly suspect that using setWorkflow(false) before a gliderecord update (did this in a fix script) did not prevent a flow designer flow from executing.  Is this a known fact/issue?  I looked thru docs/api/community and did not find anything explaining the relationship between setWorkflow(false) and flow designer.  Anyone know for sure?

Thanks!

[maynartt · Accepted solution]

I've finished working with HI on this question.  We found that they were triggered even when I put setWorkflow(false) before an update in a fix script. We proved that out using examples/testing. Here's the agent's applicable comment from that case/incident:

As per our documentation, the setWorkflow() function "Enables or disables the running of business rules, script engines, and audit". It does not specifically state that it will disable the flow/workflow engine however I thought that it would considering that there are plenty of tables where the workflow engine depends on certain business rules. For example, the Service Catalog application or Knowledge application have business rules integrated in their workflow/flow engine to tell them when to start/stop. In those cases, using the setWorkflow(false) function would cause their workflows/flows to not run. The quote from the documentation was for scoped applications and since a scoped application's workflow/flow engine is triggered by the engine itself, the setWorkflow(false) function would not disable flows from running.

So the consensus here is that the 'setWorkflow(false)' function "can" stop the workflow/flow engine from running but, it depends on what table you are on. For scoped applications, it will not stop workflows/flows from triggering unless you have implemented business rules to dictate when to start/stop the flow. The setWorkflow(false) function will only stop business rules from running and is not directly correlated, but can be, to the workflow/flow engine for scoped applications.

As a result, enhancement request FTASK45900 has been created in HI with this text:

When running the setWorkflow(false) function on a custom table, it does not stop the flow engine from running. Instead, it only stops business rules contrary to its name. Since this is confusing to the end user and contradicts its name, I would like to have this functionality with the setWorkflow function where it would also stop the workflow/flow engine from running.

[JLeong]

I believe this is fixed in Paris.

[maynartt]

I believe so, too, but I haven't yet proved it out.  The enhancement request I mentioned above was converted to an idea, and on 27Oct2020, I received an email from the Community Team stating the following:

The state of idea Prevent flows/workflows from running when GlideRecord setWorkflow(false) is used has been marked as Already exists
This idea was implemented via PRB1381927: https://hi.service-now.com/nav_to.do?uri=problem.do?sys_id=76240fdfdb1ec810feb1a851ca96196a

When I tried looking at the PRB, I didn't have access.  In addition, I reviewed the Paris release notes and didn't find reference to this PRB.  I could have missed it.

[Karthick Nagara]

tested this with one of my custom tables (on the GLOBAL scope). It works fine. The setWorkflow(false) method prevents the insertion of records into the sys_flow_context and sys_flow_plan_context_binding tables, which means that the flow I have set up (to trigger on update of a record in the custom table) is not getting triggered

[rajasekharteja]

Hello @Karthick Nagara ,

I'm facing one issue where there is an existing line "current.setWorkflow(false);"  present in After update Business rule and it's stopping the flow designer to run the flow when we submit a record from draft state is there any other way we could trigger flow without removing this line of code.

Your inputs would be highly helpful.

Thank you,

Raj