A Channel Is an Address, Not a Dropdown

The requirement said bundle availability is channel-driven.

So the first move is obvious. Open the cart, find the channel control, flip it, watch the product list change. Twenty minutes later there is still no control, and the working theory has become "the toggle hasn't been built yet".

There is no toggle. There was never going to be a toggle. The channel is not a value in this application — it is a different application.

Three Channels, Three Different Answers

The bundles in that story existed across three sales channels, and each one had a completely different relationship to the system in front of me.

The telesales channel is the cart. That is the one the Salesforce test cases cover, and it is the only one they have ever covered.

The external self-service buying journey is a separate application. It is tested on its own, by its own workflow, and nothing I do inside Salesforce reaches it.

The affiliate channel shows none of these bundles at all. Not a variation — an absence, and a deliberate one.

None of that is a defect. It is architecture, and it was decided long before the story was written. But the story said "channel-driven", the tester read "there must be a channel selector", and the gap between those two readings is a morning of hunting for a control that does not exist plus a bug report that would have been closed as by-design.

Why the Word Hides the Boundary

A channel behaves like an attribute in every sentence anyone writes about it. Availability is channel-driven. This offer is channel-specific. Configure it per channel.

Attributes live in fields. Fields live in one system. So the language quietly promises a single place where all channels are visible, and the architecture rarely delivers one.

In practice a channel is an address. It tells you which application to open, which actor is sitting in front of it, and which team owns the workflow that tests it. The requirement writer knows this and does not think to say it, because to them "the affiliate channel" names a business partner and a portal, not a picklist value.

The same trap arrived in a different costume on an amend journey. The story was called an amend journey and gave no indication of a system boundary anywhere in it. The soft variant is performed by a telesales agent in Salesforce. The hard variant is performed by the end customer, in an Experience Cloud portal.

Different system, different actor, different test approach, one story title. A tester working from the story alone writes the whole suite against Salesforce and never learns that half the journey lives somewhere they never opened.

Name the Address in the Scope Line

The fix is unglamorous and it works. Put the system in the name of the test scope, not just the journey.

Not "Amend Journey". "Amend (Salesforce)" and "Amend (Experience Cloud)" — two entries, side by side, from the moment the scope is drafted.

The value is not clarity for you. You already know. The value is that the second entry becomes visible to everyone who reads the plan: the person estimating it, the person assigning it, the person who notices that nobody has access to the portal yet. An unnamed channel is not a risk anybody can act on. A named one with no owner is an obvious hole in a document.

Two entries also force the question you actually need answered early: is that second system even reachable from where we test?

The Boundary That Is Not Yours to Trust

Everything above pushes toward the same instinct: figure out who owns each channel, then stay inside your own. That instinct is right for test design and dangerously wrong for regression scope.

A platform decommission made that concrete. The external self-service buying journey appeared in yesterday's scope as one token line, on the reasoning that another workflow tests that app. Reasonable ownership logic. It was promoted to a full six-variant regression area.

The reason is not political, it is physical. Orders created in that external application land in Salesforce carrying the same data and hitting the same order, asset and pricing layer the decommission is removing. Whoever owns the front end, the writes go through the layer that is being taken away. And a production defect where that app's billing callout failed is standing evidence that the layer really does break, in that direction, on that channel.

Ownership answers who executes the test. It does not answer what is at risk.

• When a platform layer changes, scope by where the data lands. Every entry channel that writes into the changed layer is in scope, external or not, regardless of which team owns its interface.
• When feature behaviour changes, scope by where the behaviour lives. Availability rules, screen validation and journey logic stop at the application boundary, and testing them in the wrong app produces confident false results.

Two different questions, two different boundaries, and the mistake is applying either answer to the other question.

The Map Is a Ten-Minute Artefact

Before writing channel or availability conditions, write the list. Every channel the requirement names, and next to it: which application, which actor, which environment, who tests it today.

It fits on half a page. It takes ten minutes with the right person on the call, and it is the artefact that most projects assume exists and cannot produce when asked.

Without it, a tester will do the reasonable thing every time — look for the channel inside the app they were given, find something that resembles it, and report a result that is precise, well-evidenced and about the wrong system entirely.

For the channels in your current scope, can you name which application each one actually lives in?