Three Tickets, One Inactive Journey
Two functional defects in the Modify journey and a third ticket saying the journey was inactive — all filed on the same day. Which one you read first decides whether you have a broken feature or one blocker.
Three tickets landed on the same day, all against the same journey.
One said a porting email was not sent. One said a promotion could not be deleted. The third said the Modify journey was inactive in the QA org.
Read them in that order and you have a feature falling apart. Read them in the other order and you have one blocker and two tickets nobody can trust.
What the Third Ticket Changed
Whether a journey is active is not a test result. It is an environment precondition.
The distinction decides what your defect queue is worth. If the journey is switched off, then every step inside it fails — and each failure looks exactly like a functional defect, because from the tester's seat it is a step that did not work. The email did not arrive. The promotion could not be removed. Both statements are true.
Neither of them is evidence about the feature.
Why a Junior Files Three Tickets Instead of One
Because every ticket is individually defensible.
A tester working through a test suite hits a step that does not behave as the case describes, reproduces it, screenshots it, writes it up. That is the job, done properly, one row at a time. Nothing in the execution of a single case asks the question that would have collapsed all three tickets into one.
The question is: is the thing I am testing inside actually running?
The cost of skipping it is not just wasted triage. An inactive journey does two damaging things at once — it blocks an entire family of tests, and it manufactures functional defects that a developer will investigate, argue about, and close as environment issues. The queue gets longer while the information in it gets worse.
And when the journey is switched back on, nobody knows which of the earlier tickets were real. They all have to be run again, which is the retest cost of a defect that never existed.
The Precondition Is Its Own Check
The fix is not effort or diligence. It is one line placed before the first case in any journey-based suite: confirm the journey or flow is active in this org, then start.
Thirty seconds, once per environment, per test session. It converts a wave of false positives into a single blocker with the right owner and the right title.
It is also the better artefact politically. "The Modify journey is inactive in QA" gets acted on. "Three Modify bugs" gets scheduled.
The Same Question, Pointed Outwards
There is a second version of this, and it is harder, because the unverified precondition lives in somebody else's head.
A VoIP fix was going to production the next day. The developer's position was that the agent-facing evening-and-weekends voice flow was already working fine, and that QA should just go and validate it in the other environment.
By then QA had already established two things. The specific package — a particular broadband tier combined with the evening-and-weekends call plan — could not even be re-created in the QA org. And the change from the always-on call plan to the evening-and-weekends one did not work at all in Salesforce.
The reply to that evidence was: Ok got it, now proceed to validate in the other environment.
No ticket. No correction. No trace.
Why "It's Already Working Fine" Survives
It is the cheapest sentence available to anyone under delivery pressure. It costs nothing to say, it requires no evidence, and it moves the burden of proof to the person with the least time.
It usually survives right up to the moment QA produces a receipt too specific to wave away. Not "it does not work" — that invites a debate about environments and data. But "this exact package cannot be built in this org, and this exact transition fails" is not a disagreement any more. It is a fact, and facts end conversations that opinions extend.
The claim then evaporates quietly and everyone moves on as if it was never made. Which is exactly the mechanism that brings the same false all-clear back next release, because nothing was written down that would contradict it.
What I Would Do Differently
Two things, and they are one discipline pointed in two directions.
Verify the precondition before you report anything inside it — the journey is active, the flow is on, the org has the code. And when a "works fine" claim collides with your testing, answer with the most specific artefact you hold, then put the concession somewhere the project cannot forget it.
A verbal "Ok got it" with no ticket behind it is indistinguishable from the bug never having been raised. Six weeks later, that is exactly how it will read.
In your current environment, when did anyone last check that the journeys under test are actually switched on?