Hi @Mike_Cash! Apologies for the delay in circling back here
It sounds like you've already accomplished quite a bit in Retool! 
I think the tricky (and powerful) part about Retool is that it is so customizable, so there's probably many ways to solve your case, and it's a little hard to say exactly what would be most efficient. However, here are some thoughts that come to mind as you're building.
You can "skip" queries when you have null submissions in a few ways. First, you can have success event handlers that only run when some condition. You can put Javascript in this field by wrapping it in {{}}.
You can also disable certain queries based on some Javascript condition in the advanced tab of the query:
You could also have some form validation that only lets a user submit the form when there are no nulls, although it sounds like nulls are OK for your use case. Our form docs go into more detail.
It sounds like the tricky part with your case, is handling the case of 'skip this record and move on to the next one'.
You could trigger queries on success of one another, but if a query is disabled or prevented from running based on null inputs, it won't trigger a success or failure event handler and the chain of queries will stop. One approach is that you could create lots of event handlers for every possible null submission.
Another approach could be to use the JS scripting method that you mentioned above. You could loop through each record, check if it needs to be submitted, and trigger the query if necessary. I haven't found a great example of this, but I did find this post which shows a different use case of triggering multiple queries from a single JS query
Another approach could be to create many success handlers (one for each record) that all trigger at the same time (when the form is submitted). With this approach, you could prevent certain queries from running for null submissions without having to worry about impacting other queries. Something to keep in mind here is that running too many queries at once can lead to performance issues.
Another thing to keep in mind is that the form doesn't inherently save the end user's work, so if they close or refresh the app before submitting, none of the queries will have run yet and they'll have to start over. Not sure if that matters for your use case!