No matter how good you do something, the user will screw up and ask for a way to correct things, especially important for corporate systems.

Users gonna be users

They will screw up and then ask you to fix whatever they did wrong.

Some places might tell them “Oh well, good luck next time” or “Follow this thousand-step guide without missing any step, and then you'll be able to fix that. Maybe.”.

This sucks, people will complain. Some will understand, and some will stop using it.

In some places this is not a “loss” (for the company), but in others…

Sometimes that’s not an alternative

If you’re working with corporate systems… When you don't account for the user screwing up, then if your software doesn't have a way of fixing errors… someone will have to fix it somewhere somehow.

The problem with that approach is the lack of control and possible side effects of those manual changes. Not to mention, it's easy to end up changing the wrong things either because it's distributed in multiple tables or too similarly (or poorly) named.

The user will teach you!

I like the following quote that I believe to be appropriate to the matter (edits are, obviously, mine):

There is no teacher but the enemy user. No one but the enemy user will tell you what the enemy user is going to do. No one but the enemy user will ever teach you how to destroy and conquer awe them with your software. Only the enemy user show you where your software are weak has bugs. Only the enemy user shows you where he is strong enjoying your software. And the rules of the game are what you can do to for him and what you can stop him from doing to you themselves and to your software.
― Orson Scott Card, Ender’s Game

Two approaches

You can either screw the user, or the user will end up screwing you.

And I think most people will, unfortunately, think like this…

The third, and better, approach

Instead of thinking about the user as an “enemy”, you can think of them as a teacher and as a colleague (and in the case of corporate systems it literally is!) who will help you and your software succeed.

Some people will “outsource” much of this to designers and other people to such an extent that they will never see a user that will use their software. On the other hand, the users will never meet a developer.

And you will end up with people making software for someone they never saw and users using software made by someone who knows nothing about them.

Communication and learning, together

While you can’t talk to every user you will have, you can and should have a quick way to get input and feedback from a few selected ones.

Afterward, keep getting their and other users’ input.

You will be surprised, but the user is usually a wild entity that doesn’t work by the rules you think they should. So, you need to talk to them, find out what they actually mean and not just what they say and from there iterate.

There will be people doing this to you, maybe, but that doesn’t exempt you from first hand experience with the user.