I am re-building an automation using the AppSheet API. There are 3 steps each adding rows into different tables. The last step relies on a previous step in order to obtain the “parent” row keys and create the necessary relationship.
However, when I run the Bot that last step is indicating that there were no rows created. I have tried various versions and can get rows added in some instances. I get the “no rows” issue when I use the necessary SELECT to retrieve rows added by the previous Bot step - to get the row keys.
This leads me to believe that the rows added in the prior step are simply not in the datasource to be SELECTED but that doesn’t technically make sense. So I am thinking I am doing something wrong but it’s so simple I can’t imagine what.
Has anyone tried using the API in this way - retrieving a row added in prior step and using its data in a subsequent step?
I have not tried it. But I would not expect it to work how you are wanting.
Consider how the app running on a user’s device is in a certain “state” since the last time they synced. If another user makes a data change, the first user can’t see it until they sync and update their state.
I think Bots also run in a specific state, it’s just held on the Appsheet servers instead of a user’s device. The Bot’s state is set when the Event is first triggered.
Updating/adding/deleting records via API would always be done “out-of-state”, or in other words; processed in another instance of the app, in a different state, and thus not available until after another sync is made.
I think if you created a new Bot, which triggers on the adds/updates from the first Bot’s API calls, you can accomplish what you need?
To be clear, this is mostly conjecture, but it certainly makes sense to me.
2 Likes
But I would expect it to work like actions on a device. If I start a set of actions, I CAN access rows added by a previous action within that same set of actions. I think this is because all the action updates go to the datasource stored on the device.
Likewise, I would think that a bot running a set of steps on the server would experience a very similar behavior.
Which is exactly why I said an API call would be “out-of-state”.
Remember that Appsheet webhooks are “fire and forget”. With the API webhook, your Bot handed off the row creation to another instance of the app, and then your Bot continued on its way, not caring, or knowing, about what that other instance was doing.
In fact, that’s probably all I should have said in my first post…
3 Likes
Ahh, I get what you mean now.
The bot steps are happening fast enough that rows are not yet available in the datasource. I should have realized this.
I put in a “Wait on Condition” and it now produces what I need in that last step. I also had an issue with some App Formulas not computing correctly which I think were related to the same issue. I turned off “Run Asynchronously” and it now all seems to run fine. I know it’s a little slower than “Asynchronous” but still much, MUCH faster than running through actions.
Thanks for steering mw in the right direction Marc!!
2 Likes