When Should a System Stop the User, and When Should It Only Warn Them?

The user wants to continue. The system says a condition has not been met and blocks the operation. Technically, everything works exactly as specified — except that in this particular case, the user has a valid reason to proceed.

This is where the difference appears between a system that merely enforces rules mechanically and one that sensibly supports a real process. Not every deviation is an error, and not every “should be satisfied” means “continuation must be prohibited under all circumstances.”

When designing a process application, it is therefore not enough to decide what should be checked. It is just as important to decide what the system should do when a check fails.

One Validation, Two Completely Different Meanings #

In the application, several conditions were checked before certain operations. At a technical level, they looked similar: the system determined the current state, compared it with the expected state, and decided whether the condition was satisfied.

The important difference was not in the code, but in what the rule meant.

The first group of conditions effectively said: if this rule is not satisfied, the operation would create a state that the system must not allow.

The second group meant something else: under normal circumstances, the rule should be satisfied, but in real operations there may be a legitimate reason to continue even when it is not.

If the system does not distinguish between these two situations, it is easy to end up with an application that looks strict and consistent while failing to reflect how the process actually works.

The distinction between a hard stop and a soft stop is not unusual. Infor Workforce Management, for example, uses the same terminology for validation rules: a hard stop disallows a transaction, while a soft stop displays a warning and lets the user proceed after acknowledging it.

When Blocking Is the Right Choice #

Blocking validation makes sense when the system can determine with sufficient certainty that proceeding is not allowed.

A typical example is an attempt to move into a state that cannot legally follow the current state. The same applies to an operation missing a mandatory reference record, or to a situation where proceeding would create an internal inconsistency in the data.

In that case, the system’s job is not to warn the user about a risk. Its job is to protect process consistency.

A “Proceed anyway” button would make no sense here. The user should not be asked to decide whether they want to create an invalid state.

Not Every Process Rule Is Absolute #

Conditions that describe the expected course of a process are different.

Something was supposed to be completed. A certain piece of information was supposed to be available. A previous step would normally have been performed. But the system may not know everything that the person dealing with the specific situation knows.

This is where a hard block can be too strong.

If a legitimate exception occurs once every few weeks, the application still needs a way to handle it. The user should not end up in a situation where a valid working procedure exists, but the system prohibits it simply because its data model cannot capture the full context of reality.

The result is often not a better-controlled process. The operation is postponed, handled outside the system, escalated to an administrator, or someone finds a way to satisfy the check formally without making the data describe reality any better.

Research into hard-stop mechanisms in healthcare information systems shows the same underlying problem in a much more critical environment: strict blocking can be highly effective, but inappropriate use has also been associated with avoidance of the blocked workflow and delays. The authors of a systematic review therefore recommend using hard stops judiciously.

The point is not to transfer healthcare rules into a business application. The useful principle is more general: the stronger the system’s intervention in a user’s decision, the more precisely it must be defined when that intervention is justified.

A Soft Stop Should Not Mean a Routine “OK” #

The alternative was not to remove validation. The check remained; what changed was its outcome.

If a condition that could legitimately be overridden was not satisfied, the system showed the user exactly what was missing and what the actual state was. Instead of a blind prohibition, the user could decide whether to cancel the operation or consciously continue despite the warning.

That is fundamentally different from an ordinary informational dialog.

A good soft stop should not merely say:

“The condition is not satisfied. Continue?”

The user needs to know which condition failed, what state the system expected, what state it found, and what continuing means.

The confirmation then stops being a click required to dismiss an annoying window. It becomes part of the decision itself.

Too Many Warnings Are Also a Problem #

None of this means that every block should be replaced with a warning.

Warnings have a cost too. They interrupt work and demand attention. If a warning appears frequently and the usual response is simply to click “Continue,” users learn to do exactly that.

Research on user behavior around security warnings has shown that repeated exposure leads to habituation: users gradually pay less attention to the warning.

For a process application, that suggests a third category as well. Some conditions should be neither a hard stop nor a soft stop. If the user does not need to act at that moment, a non-blocking piece of information — or no warning at all — may be more appropriate.

The goal is not to maximize the number of validation dialogs. The goal is to make the user pay attention precisely when their decision actually matters.

An Exception Must Remain Traceable #

Allowing the user to proceed despite an unmet condition must not mean that the system loses control of the situation.

If a user consciously overrides a control rule, that fact becomes part of the process itself.

The history can therefore record who continued, when it happened, which condition was not satisfied, what the actual state was at that moment, and, where appropriate, the reason the user provided.

The audit trail then answers not only “what happened?” but a more important question: did the system know about the deviation, and who decided to continue despite it?

This approach is consistent with general audit-record principles. NIST states that an audit record should establish, among other things, the event type, when it occurred, its outcome, and the identity of the subject associated with it. It defines an audit trail as a chronological record that allows the sequence of events to be reconstructed.

The Decision Is Not a Technical One #

When designing a validation rule, it is therefore useful not to start with the question of how to display an error message. First decide what the rule actually means in the process.

The resulting implementation therefore did not divide checks according to how easy they were to code, but according to the consequences of violating them.

A critical rule protected the system and stopped the operation. A control rule warned about a deviation, left the final decision to a person, and preserved that decision in the history.

That may be a small difference in the user interface, but it is a substantial difference in process design.

A System Should Not Decide When It Does Not Have Enough Information #

In digitalization projects, it is tempting to turn every word “must” in a process description into a condition in code. That creates the impression that the system will enforce the process.

In reality, every such rule needs one more question: is this genuinely an absolute rule, or merely the expected normal state?

If proceeding would objectively be invalid, the system should stop the user.

But if the decision depends on circumstances the application cannot fully know, it may be better to identify the deviation clearly, request a conscious decision, and record it.

A good process system should not merely enforce rules. It should also know which decisions belong to the system and which still belong to a person.

Sources and Further Reading #

• Infor Workforce Management: Shift Edit Validation callout
• Powers et al.: Efficacy and unintended consequences of hard-stop alerts in electronic health record systems: a systematic review
• Vance et al.: Your memory is working against you: How eye tracking and memory explain habituation to security warnings
• NIST: SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST Computer Security Resource Center: Audit trail