Who Can Actually Click Approve
A readiness risk was closed by a stakeholder confirming the manager roles were live. The first end-to-end run produced a Highest-priority defect: the manager could not open the Approvals app.
"Manager roles are now live."
That sentence closed a risk on our board. The first end-to-end execution against it produced a Highest-priority defect: the manager persona could not open the Approvals app at all.
Not the wrong queue. Not an invisible record. The app would not open.
The Risk We Had Written Down
The analysis for out-of-threshold discount approval flagged manager persona readiness as an environment risk, and marked it a hard blocker for the end-to-end approval tests.
That was the correct call. You cannot test an approval loop without somebody who can approve.
So the risk sat waiting for a confirmation, and it got one — from the technical design forum, on the record, before execution started. Roles are live. Risk closed, tests unblocked.
Two Security Layers, One Sentence
The confirmation was accurate. It answered a different question than the one the risk had asked.
Role Hierarchy placement governs record visibility and approval routing. It decides whether a manager can see the request and whether the process sends it to them.
Access to the Approvals app is a Profile or Permission Set grant. Different layer, different owner, different screen in Setup.
"The roles are live" is true of the first layer and says nothing about the second. A statement about one security layer quietly passed as a statement about all of them, because both get called "access" in conversation.
What the Analysis Had Assumed
The analysis recorded that the approver and the requester sit on the same Profile, and that Role Hierarchy position was what separated them.
The org did something else. Approvals route through a public group plus a permission set that grants the Approvals app, on a Flow-based approval process. And the whole arrangement is a temporary technical scaffold — it stands until the business decides who approves and how.
So the analysis named a business persona and stopped there. "Approver" is a role in the requirement and a grant in the org, and the two are joined by whatever mechanism the build happened to pick: Role Hierarchy, a public group, a permission set, a queue. Naming the persona does not identify who can click Approve — and it sets up the wrong org, because you go and configure the layer you guessed at.
One Handshake Arriving as Two Tickets
There is a second reason this gap survived analysis.
The requirement came in as two stories that read like independent work. One for the agent requesting approval, one for the manager approving or declining. Two tickets, two analyses — except they are the request side and the decision side of a single handshake, sharing one approval process and one set of decisions.
Split that way, each analysis tests half a loop. A request that goes nowhere, or a decision with nobody waiting on it. And the assertions that live in the seam belong to neither ticket: the routing, the lock on submit and the unlock on approve, and the one easiest to lose entirely — the requester must be notified on rejection exactly as they are on approval.
Nobody owns the seam when the seam is between two backlog items.
What This Was Not
It was not a defect in the approval process. The process worked.
It was not a Role Hierarchy problem, which is where the analysis would have sent anyone who went looking.
And it was not an expensive miss. It surfaced on the first end-to-end run, in sprint, as a bug with an owner — not in UAT with a release date attached. That is the whole return on writing the readiness risk down in the first place. The risk was right. Only the closure was wrong.
How a Readiness Risk Actually Closes
Not by a stakeholder saying it is configured. By logging in as that persona and touching the exact surface the test needs.
Open the app. Open the record. Click the button the scenario depends on. Thirty seconds, and it either works or you have a defect a week early.
The "who?" question you ask of every scenario applies to preconditions too, and it does not accept a job title as an answer. It wants the grant.
One more thing follows from the scaffold. When the mechanism is explicitly temporary, do not write the negative test against the mechanism — write it against membership. "A user outside the approving group cannot approve" survives the day the public group becomes a queue, or a role, or whatever the business decides next. "A user below the manager role cannot approve" does not.
When a risk on your board says the environment is ready — who logged in, and what exactly did they click?