@colbyturybury
Yep! I know exactly what you are talking about as I've built that app!! Field service. The guys have spotty internet or none. They need to keep on going disconnected and when they connect, all submits then submitted.
In that app, I essentially have a collection that acts as a Queue.
Now, my app is a bit more complex because there are many different tables/lists that data goes to. So a single collection for each datasource would have been overkill.
My approach instead was a generic Queue collection. In that collection is stored a JSON formatted text of the record for the data source.
Once the internet signal comes back, there is a timer control that becomes enabled and the queue is all sent to a PowerAutomate flow as one "payload" of multiple JSON "actions". The flow then is designed to know what to do with each action.
SO...forms did not apply in this case because there was just too much customization for controlling the above steps. Things needed to either submit (to flow) when done, or store in Queue for when connected, and save to device in case of crash.
What ultimately became the architecture was that everything went through the Queue. The controls around the queue would determine connectivity. The queue was ALWAYS saved to device when it had a new action in it (in case of crash or spotty internet where the connection would be lost during the transaction to the flow). Then a constant queue timer would repeatedly do the connection check and try to empty the queue. If so, it cleared the queue and stored, if not, it would pick up on the next timer end. Another key to this was a transaction ID from the flow. If the app did not get a transaction ID back from the flow, it considered it not done.
Incidentally...waiting on a complex flow to complete can take a long time - enough time for the field tech to lose connection. So, the "front-end" flow is quick. It takes the payload sent and stores it and then returns a transaction ID. In this particular app, the payload is stored in SQL and then a trigger fires to process it, but the app doesn't have to wait for that...just the flow - very quick.
There are a lot of other aspects to the app and that process that I could write a book about. The app has been in use for over a year now with up to 200 techs working on it in the field daily. So far no data loss or complications. (knock on wood!)
So yeah...kind of familiar with what you are doing 😉
