Nothing reaches SAP unapproved

The reason this is structural

It is easy to build a system that asks permission and hard to build one that cannot fail to.

The usual approach is a check: before executing a write, confirm somebody approved it. The problem is that such a check has to fire at the right moment, in the right order, relative to everything else in the system, and the order is not always obvious. We have watched a correctly written permission check deliver its refusal after the human had already been shown a prompt.

So the design removes the ordering question. Preparing a change and executing one are separate operations, and the executing one takes a reference rather than a payload. It names no entity, no fields and no values. If no validated change exists, there is simply nothing it can do, not because it is stopped, but because there is nothing there.

Validated before anybody is asked

By the time a change reaches a person it has already been checked against SAP’s own contract: that the entity accepts writes, that the fields exist, that the types and lengths are right, that the required values are present.

This is partly courtesy (nobody should be asked to approve something destined to fail) and partly about what approval means. An approval screen that regularly shows changes SAP then rejects trains people to click through it.

Saying no

A rejection carries a reason, and that reason goes back into the conversation rather than into a log. The identical call is then blocked for the rest of the run, so the response to “no” is a different proposal, not the same one asked again more emphatically.

Everything is recorded either way: what was proposed, what was validated, what was approved or refused, and what SAP returned. A refused write is as visible as a completed one, which is the part that makes the record worth having.