Action 'add row to another table' - only firing through workflow

Hi. I’ve hit a wall and need help.

I’ve an action to ‘add another row to another table’ that only works when fired via a workflow.

I’ve tried firing the same action inline and prominently and it doesn’t fire.

I’m able to add rows to other tables via actions both prominent and inline and yet there seems to be something about this table in particular that I can only add a row via a workflow.

I’ve rebuilt the table from scratch and it has no unresolved ‘required’ columns.

Currently the data change workflow is being fired by an inline action to change a ‘trigger’ column a ‘personnel’ table. This is a workaround but it means I’m unable to get the addition to the ‘timesheet’ table to fire another as workflow I’d originally intended as this becomes a workflow firing a workflow and is not (as I understand it) possible.

I’ve created many ‘add a row to a table’ actions in the past in exactly the same way and so I can’t work out what’s wrong with this action or table.

This is one of my pet peeves with actions and workflows - we have so little visibility into how they are being sequenced and executed. We are simply trying permutations and combinations and hoping one of them will work.

1 Like

HI Tim,

I am sorry but I am having trouble understanding what you are reporting.

It is true that Data Changes that are invoked by workflow rules do not trigger subsequent workflow rules. This is described under topic “Workflow Rules are Not Triggered” in this article https://help.appsheet.com/en/articles/961707-workflow

We may change that behavior at some point, but I am concerned that such cascading workflow actions might cause a lot of confusion and “infinite regression” problems.

I am not certain what actions you wish to invoke. A workflow rule can invoke a “Grouped” action that performs two or more child actions. Would that help you accomplish what you need?

You wrote “I’ve an action to ‘add another row to another table’ that only works when fired via a workflow. I’ve tried firing the same action inline and prominently and it doesn’t fire.” Do you think you have uncovered a bug, If so, I suggest creating a simple test case that illustrates the problem and submitting that test case as a problem report.

1 Like

Phil

I totally understand regarding the risk of infinite regression and it was for this reason that I’d hoped to fire the first action with an action button. But for some reason I’m unable to get the action button to fire an ‘add a row to another table…’ to the particular table I’m hoping to add a row to. I can add to other tables, using a copy of the same action, and, as I say, the original action can be fired through a workflow but that’s not the functionality I need.

I’ve tried recreating the same difficulty in a new app of two new tables but it fires as expected and so it seems to be something to do with this table in particular. I’ve also recreated the same action in another app with the same table and again it fails to fire on an action button.

Ive created a workaround using trigger columns and copying lots of Key columns but it feels overly complicated.

If the issue occurs again I may be able to figure it out but I wondered if there was anything I should be looking for to explain it.

I’ll see if I can create a simple app with two tables, one being the troubling one to see if it repeats the same issue. I’ll feed back.

Thanks
T

Do the table’s permissions in the app allow the action?

Do you have a security filter on the table?

Hi Tim,

I asked for a simple test case because it makes it easier for us to find and fix the problem.
It is also safer, because we can reproduce the problem with your simple test case rather than trying to do so with your real application.

Normally, when we are diagnosing a problem, we need to reproduce the problem several times in the debugger while stepping through the code. After we have a fix, we need to repeat the steps again to ensure our fix resolves the problem. Depending on the repro steps you provide to recreate the problem, that can involve adding, updating, or deleting records to your tables . We like to avoid doing this with your real application, if possible, for obvious reasons. However, if you can only reproduce the problem with your real application and you are prepared to accept the risks of having us debug using your real application, we can do that.

1 Like