Hi Daniel, as in so many cases the answer is “it depends”. Without knowing your system this is hard to say.
The most common way to suspend the flow is to suspend or even disable the trigger on IS side, this will make the messages remain in UM queue for later processing.
You need to understand what such a queue would mean for your sending systems. Would they run into timeouts and worst case have an logic of resubmission. In this case you would get duplicates or even worse of your input feeds inside the UM queue.
You also need to know your queues and event parameters. UM support overall QUEUE and also Event specific time to life (TTL). If that is setup to be lower than your time of queue you will lose transactions because you system will wipe them from the UM queue automatically.
You wrote: “disabling the trigger causes new messages to be not queued on the UM.” – this sounds like there is such an TTL configured.
You need to be sure you understand your overall solution to be “thread save”. This means that even you queue and later process the backlog, you need to know if change the execution sequence different from the time of arrival in your queue would be an problem for your data integrity. Unless your queues and triggers are configured to work single threaded / serialized, it is possible that the execution order is not the sequence in that your incoming messages arrived.
So the best is for sure also to inform your sending systems to suspend their feeds to you, so you now get messages to queue.