Seven Seconds of Approved

The discount was gone. I refreshed the page. It came back.

That is the whole bug, and it took me longer than I want to admit to understand what I was looking at.

The Setup

Salesforce with a CPQ cart. Agents can apply a discount that needs a manager's approval. The agent hits Save & Apply. An Approval column appears with a green tick and the word Approved.

Behind that screen, an after-save Flow decides the real outcome. It reads the amount, checks the configured thresholds, and stamps the record: auto-approved, or routed to a manager.

Two systems. One screen. That is where this lives.

The Symptom

I deleted a discount from the cart. The row disappeared. Normal.

Then I refreshed, out of habit more than suspicion. The discount was back.

My first thought was caching. My second was a UI defect. Both were wrong, and both would have produced a bug report that wasted somebody's afternoon.

The Investigation

I stopped theorising and queried the record.

It had never been deleted. IsDeleted was false. Same Id. No error toast, no failed transaction, nothing that looked like a rejection.

Then I looked at the timestamps.

The record was created at 09:00:00. The after-save Flow stamped it Pending / MANAGER at 09:00:07.

Seven seconds.

My screenshot of the green Approved tick sat inside those seven seconds. The cart had painted a status the database never held.

And the delete action? It is exposed only when the status reads Approved or Rejected. So the UI offered me a button based on a state that was already stale, I clicked it, and it fired against a record sitting in Pending.

The delete failed. Silently. IsDeleted stayed false, and Application_Error_Message__c — the field the technical design created for exactly this failure — was never populated.

The Root Cause

The cart renders approval state optimistically. It shows you the likely answer while the flow that actually governs the record is still running.

For a few seconds, the screen and the record disagree. Every action the agent takes in that window is validated against the screen and executed against the row.

That is the whole mechanism. It is not exotic. It is what optimistic rendering does when nobody asks what a user can do while the system is still thinking.

What It Was Not

I nearly wrote this up as a critical escape. Unapproved discount. Delete bypass. Governance broken. You can feel the severity climbing while you type.

So before writing, I tried to exploit it. I could not.

The checkout gate held, because it queries the record rather than the screen. An unapproved discount still cannot get through. The damage is not a bypass — it is a trap: a misleading "automatically accepted" message, a delete button that does nothing, and silence where an error belongs.

That distinction matters more than it looks. A bug report that overstates severity gets corrected in public, and the next one you file starts from a worse position.

What This Changes in Testing

When a governance flow runs after-save, the UI state and the record state are two different truths separated by a window of time. Three things follow.

• Assert the record, not the screen. If the status looks right, query the row before you believe it.
• Diff CreatedDate against LastModifiedDate. That gap is the width of the window, and it tells you how much room a user has to act inside it.
• Treat every action the UI enables during that window as its own test condition. "I clicked delete and it worked" and "the row is gone" are not the same claim, and only one of them is testable.

Most test cases check the state before and the state after. This defect lives in the middle, and no amount of end-state assertion will ever reach it.

The Uncomfortable Part

The screen is a rendering. The record is the fact.

That sounds obvious written down. It did not feel obvious at 09:00:03, looking at a green tick that was telling me the truth about nothing.

When was the last time you queried a record instead of trusting the status on your screen?