The best solution is of course to understand the errors being caught and build more resilience into the end to end integration solution, wherever it's appropriate.. But I've had this before, for example where the source system that generated the message couldn't be customised to make certain fields mandatory, even though they would be required in F&O, so there were a lot of validation errors being caught.
You can have a LogicApp triggered by messages arriving in the dead letter queue that handles the various exception types.
My solution was to have a couple of tables in a SQL database. The LogicApp would parse the error and insert a record for the table & key fields of the message that caused the error (also had some fields to track the action taken and if the error was resolved - really useful for sys admin to track and report the errors being caught and identify any that didn't get resolved.) The other table provided a mapping between parts of the technical error that were captured and a 'friendly' message that could be sent to end users to guide them on resolving the issue e.g. an email sent from my email address by the LogicApp:
"Hey <user>, I see you created a new product in the system. Unfortunately the description you entered was too long for it to fit in Dynamics, so the integration failed. Please can you go back and edit the description, keeping it under ?? characters. That should fix it! Thanks, Chris."
There was more to the solution than I've described of course, for example when an exception was caught that didn't map to a friendly message it would email me directly instead so I could investigate and if appropriate create a new entry in the friendly message mapping, but hopefully that's helpful as a suggestion!
