Records created through Internal AppSheet API call ARE NOT available for follow-up tasks.

[MultiTech]

When creating records through an internal AppSheet API call, it seems that the records created in one step ARE NOT immediately available in subsequent steps.

• Apparently, you have to wait for these newly created records to be available.
• You can't create a follow-up task, like I did above, where we take the results of the previous task and work with them.

What ends up happening is:

1. The records are created
2. The next task runs WITHOUT these new records.

And FYI: my API call is not asynchronous

____________________________________________________________________________________________

My thought was to try and use return value:

• But you can't select JSON as the type
• And it seems that advanced JSON formats (like what is returned by the API) are not supported anyways.

Too bad these features aren't plug-and-play. 😞 

• It would be intuitive for these records to be available immediately for subsequent tasks
• If there is a technical reason why they aren't: being able to select JSON as the output type would likely solve this

[Denny774]

Hey,

keep it a No Code Platform ffs dude 😆

[Rifad]

---

@MultiTech wrote:

What ends up happening is:

1. The records are created
2. The next task runs WITHOUT these new records.

---

I recently encountered a specific need and now I'm stuck. Are there any other solutions? @MultiTech 

[MultiTech]

I found that using brute force works; try using a select statement to pull the records from the database. 

[WillowMobileSys]

I don't think I tried this for my issue.  I'll give it a go and report back.

[WillowMobileSys]

I have ALWAYS found issues with adding/editing rows with an API Task and those changes being available to subsequent steps.  I spent considerable time trying to find a way to get it work AND I opened a couple posts and a ticket to AppSheet - only to be told basically that's the way it works.  Baloney!  I know better!  Well - at least is doesn't HAVE to work that way!

I finally split up the workflow into several segregated Bots and that worked - it seemed the newly added rows were now "properly" available to the subsequent Bots.  This ran fine for over a year ALTHOUGH, it would occasionally hit a Time Out error.

However, sometime between 11/22/23 and 12/20/23 even the segregated Bots stopped working.  There was a release that was rolled-back during that time that I think had changes to automation.  I believe the roll-back didn't put the state of the automation back to the "usual" state.  But how do you prove that?

I could get a part of my issue to work by adding a Wait step. Which told me that there was just a DELAY in the rows being made available.  But it didn't work in all areas, I think because each Wait is a minimum of 5 minutes and adding more than 1 creates a process(es) that run too long - maybe?  Adding a wait on condition did NOT work, again because I think there is a delay in the rows being added AND/OR  they are NEVER made available to THAT instance of the API at all (which based on past expereince I believe to be the case).

I am still having these issues and spent the time creating Actions in the app to CORRECT situations when an incomplete set of rows are inserted.  I have to monitor things more closely but it works for now.

My plan is to convert the set of API calls I have into a Google script.  While the API calls are faster than using an Action-based solution, they are still wicked slow and can encounter Time Outs.  

[Denny774]

---

@MultiTech wrote:

The next task runs WITHOUT these new records.

---

Hey man,

it's just out of scope is all there is. Nothing really to do with async but rather with task parallelisms