System status vs. task failure are two separate issues. You can indicate both.
There's two errors here, and issues of time: things that are happening regardless of user input, and failure of user input (due to several possible causes).
System status isn't an error itself, but a state a user should be aware of if possible.
In this example, if I as a user am aware of connection issues beforehand if possible, I might delay doing work that I'm concerned won't persist or be successfully completed. I can anticipate errors because the system keeps me informed.
From the Neilsen Norman Group's 10 usability heuristics:
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
You could do this through a persistent info or warning band. This way the user might still use the system, but not make changes.

download bmml source – Wireframes created with Balsamiq Mockups
Errors could be handled with a single icon, but the text should be clear about what just happened, and a way to recover if possible. And inline validation can catch user input errors before the user submits their work (no dialog needed!).
Enterprise software is notorious (I do it for a living!) for having lots of error codes from a complex system where often the programmers are writing the error codes so that they can debug while they are coding. These often slip through the cracks.
Here's another reference from Neilsen Norman on designing for errors
Constructive advice on how to fix the problem. For example, instead of saying "out of stock," your error message should either tell users when the product will be available or provide a way for users to ask to be notified when the product is restocked.
In conclusion, you have two levels of information for your users:
- A potential and persistent warning that's visible: system status. This in itself could eliminate some potential loss of work.
- The error itself: If it was caused by a network problem (or other system issue out of their control), at least you've provided feedback for them to draw some conclusions about what may have happened.
Lastly, check your tech stack to see if you can use offline storage.
I don't know if you have the resources, but you could take advantage of offline storage through Progressive Web Apps. That is a whole other thread in itself, more suitable to discussions with your development team. Most enterprise software has significant technical debt, and doesn't get rewritten often, but just putting it out there. :)