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.
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.
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.
User | Count |
---|---|
43 | |
28 | |
24 | |
21 | |
13 |