If needed run your microflow from a java action using the IContext.startTransaction and endTransaction methods. If you use the sequence: - startTransaction - Core.executeAction(MF) - endTransaction
The microflow actions executed will be stored in the database and will be available in the next step of your microflow. Be aware that running a microflow like this will no longer allow rollback of the data committed in the microflow executed in the java action. So if the subsequent steps in the MF from where you trigger the java action result in an error the data created/changed or deleted by the java action will remain in tact.
In my experience the QueuedAction takes a few seconds before it is started, so it depends on how "heavy" transaction 1 is if they will be available in transaction 2. I would say that it is not 100% guaranteed that transaction 1 will be finished and therefore not a dependable solution.
What the specific trigger is I don't know, it might be that instantiating the QueuedAction is the trigger?