The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

maynartt
Kilo Guru

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!

1 ACCEPTED SOLUTION

maynartt
Kilo Guru

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.

View solution in original post

9 REPLIES 9

Jace Benson
Mega Sage

I haven't investigated but this should be stated.  setWorkflow is a flag to control if later business rules will run after the current rule.  So depending on how SN has flow designer's pickup it's stuff, It's possible it isn't a business rule at all.  On a quick glance nothing stood out to me as what is starting the flows. 

I'd ask HI for the technical how these flow's are picked up by system to process.

maynartt
Kilo Guru

Good idea.  I created CS4269361 in HI.

maynartt
Kilo Guru

Just an update.  I'm currently working with the HI Agent, but due to other items on my list, still not finished.  I need to replicate the issue so the agent can look at the resulting binlogs.  

Before we got to this point, here's what I posted (commenting after the agent directed me to the api link on the developer site):

Thank you for the link. Copying its wording here: setWorkflow(Boolean enable) Enables or disables the running of business rules, script engines, and audit. If true (default), enables business rules. If false, disables business rules. Before I accept solution, please confirm that I should assume that since flow designer flows are not listed in the documentation for setWorkflow, then flow designer flows are not affected one way or another by the setWorkflow api.

And here's the agents reply:

The setWorkflow function does affect flow designer flows since the flow engine is a scripted engine. As mentioned earlier, the setWorkflow function works to ensure the current update does not trigger any business rules or script engines which includes workflows and flows. After the current update has finished, the next update done to a record will trigger business rules and flows based on their run conditions. In summary, you should assume that setWorkflow disables flows with the exception that it only disables flows for the current update. In your case, the current update was the fix script that was ran and we see that the flows did not trigger for those updates. For the 28 flows that did run, they had separate updates done to them which then caused the flow to trigger and run for those records. I hope this clears things up but, if you have any other questions or would like more clarification, please let me know and I can digress.

What we're pursuing now:

I'm not entirely sure that "they had separate updates" as the agent stated.  We did not yet prove that they did.  Therefore I need to recreate the issue.  

THanks for the update.  I've added a brief note to my notes on https://blog.jace.pro/gliderecord#setworkflow