Do Workflow rules NOT allow "child" workflow rules to be fired?

[WillowMobileSys]

I am trying to create a Workflow rule that processes a work order when it is done by performing data updates and sending of an appropriate invoice determined by other Workflows.

I am getting inconsistent results and have spent a lot of time testing and debugging. I began researching this forum and came across a post that stated that Data Changes in a Workflow rule do not allow triggering of additional Workflow rules - this has been explicitly turned off.

Based on my inconsistent results, I was able to get an invoice sent based on Workflow Data Changes that triggered other Workflows.

So, before I spend anymore time on the problems, I would like to confirm the expected behavior with Workflows. Can “child” workflows be triggered based on Data Changes made in another Workflow?

[Bellave_Jayaram]

AFAIK, you can include multiple actions in one workflow rule (and the data changes can affect a child table or a parent table) but you cannot have a data change action in the “parent” workflow rule cause a “child” workflow rule to be triggered.

[Steve]

My understanding aligns with @Bellave_Jayaram’s.

[Phil]

Jayaram and Steve are correct.

I suspect that the post you saw was mine.

Data Changes that are invoked by workflow rules do not trigger other workflow rules.
We have never done so because we were concerned that it might cause an “infinite regress” where a workflow rule invoked a data change, that triggered a workflow rule, that invoked a data change, that triggered a workflow rule, that invoked a data changes, that …

Updates made through the API do trigger workflow rules.

I have update topic “Workflow Rules are Not Triggered By” in this article to explain this https://help.appsheet.com/behavior/workflow-introduction/workflow

[WillowMobileSys]

@Bellave_Jayaram @Steve Thank you guys

Phil:

I suspect that the post you saw was mine.

Yes, you are correct it was your post from last year I saw.

I am little puzzled as to why I could get the Email Workflow to fire on many occasions. And it was based on Data Changes from the Order Done Workflow because I “trimmed” down the functions so that the only place that the flag was set that releases the email was in there.

Regardless, with this understanding in mind, I’ll make the necessary changes.

It is a little unfortunate that emails can only be sent via Workflows. It seems having an email action would be better fit AND you can still generate by Workflow using the same construct as for data changes in a Workflow.

[Jin_Tan]

Is there any way to work around this?

I have created 2 workflow rules because the second work flow rule can only be triggered by the data changes made by the first work flow rule. Then i found out the second work flow rule would not run.

Adding 2 action under the same work flow rule is not possible because they do not share the same condition.

[Steve]

You’ll need to chain actions together from the action that workflow performs.

[WillowMobileSys]

As @Steve said, you can chain the actions together. I opened this item and after finding out the behavior was by design, I did restructure my Workflow logic to make it work, so it can be done.

Remember, a Workflow only fires off each Action and EACH Action also has its own conditions to run. So take the Action from Workflow #2 and add it to Workflow #1. Then add to it the conditions that trigger Workflow #1, if applicable.

I recognize that there are some complex conditions that make this less straight forward, such as changes made to a different tables and the need to use BEFORE change vs AFTER change logic. BUT, there are alternative ways to implement those as well.

[Jin_Tan]

Thanks. It works now.

[Phil]

I am puzzled how you ever got it to work. We are explicitly disabling it in the code. If you figure out how you did it, I would like to know.

I sometimes wonder if we are being too cautious regarding triggering workflows from Data Changes. I have considered adding an option to enable this to work. I am only reluctant because it might unleash problems that customers would have difficulty diagnosing.

Do you have a view on whether we should enable triggering workflows from Data Changes?

[Mike_A]

@Phil - I can certainly understand the concern about “runaway” workflow triggers, and it can be hard to diagnose. At the same time, there are valid use cases to have this chaining. I wonder if there is a good balance that can be designed by adding in some kind of “rate limiting” or “throttling” logic like google does for app scripts. eg: x number of workflow triggers in a given period of time, or total continuous triggers. Maybe not practical. Just thinking out loud.

[WillowMobileSys]

@Phil I apologize for the delayed response. I have been extremely busy the last few days. I wanted to think about your question and investigate more why I am seeing the Workflow be triggered multiple times. I have a better understanding now.

I have confirmed that additional Workflows are NOT triggered by Data Changes. What I was seeing was based on an action triggered on Save from the view. This action sets a flag to send an email and then sets it back immediately to prevent further emails. Thus, I end up with 3 data updates before the Workflow is triggered.

Even tough my Workflow sets an additional flag to prevent future processing of the same Workflow, those subsequent Workflow instances are not getting the updated flag value. So…either the subsequent instances of the Workflows use a static set of data based on when they were put into queue OR these Workflow trigger instances are processed in parallel and are already in flight before the data flag is set. Either way this is a problem for my current implementation.

What is the expectation for Workflow triggers on Data Changes? Are they processed in sequence or parallel? Should each instance have the most up to date data set?

On the question of enabling workflow triggers based on Data Changes from other workflows, here is my observation and experience. While you can implement “limiting”, there will ALWAYS be use cases , at some point, that need for that “limiting” to be expanded.

On the flip side, if you simply allow unlimited “nesting”, then you have the very valid concern of “runaway” processes. There MUST be robust detection methods in place to identify endless loops and/or inappropriately long processing times - in cases where the stack would eventually end but just simply takes too long to get there. Then proper notification must be sent to the owner of the offending precess (es).

I would advocate for the unlimited “nesting”, provided the detection methods could be confidently implemented. These are not new problems so there are likely well-documented coding patterns that can be leveraged.

[WillowMobileSys]

@Phil Actually, playing with this more. I think there is a critical bug happening. As each Workflow trigger happens the main sheet reverts back to original state but sheets changed during workflow processing DO NOT revert back. This means data is in a different state, causing the workflow to process multiple times and results in calculation errors.

I am going to close everything down. Refresh and restart the machine and log back in and see if I can reproduce. If I can, I will open a bug.

[WillowMobileSys]

@Phil I have refreshed all systems and ran the test again and was able to reproduce the issue. I will create a tester app that clearly demonstrates the problem and open a bug. But it seems this needs looked at and addressed ASAP. I consider it a very critical bug…if my understanding is correct of how the processing is expected to perform.

[Phil]

Hi Mike,

That is a good suggestion. I am in the process of implementing Rate Limiting now for other purposes. I could probably extend it to do what you suggest. Thanks for suggesting this!

[Mike_A]

@Phil - thanks for listening as always. You guys are very customer centric and it shows. Much appreciated!