Concept
Decisioning is the capability that chooses the next best action for a customer. It answers a single question, given everything we know about this person right now, what should happen next, and it does so independently of the channel that will carry the action. A channel sends an email or a push. Decisioning decides whether anything should be sent at all, to whom, and why.
Why it matters
The reason decisioning deserves its own name is that it is a placement decision, and placement is where architectures quietly succeed or fail. If the logic that chooses the next action lives inside one channel tool, every other channel either duplicates it or ignores it. Put the same logic in three places and you now maintain three copies that drift apart the moment someone edits one. The architectural consequence is ownership: a stack has exactly one place that owns the choice, or it has none, and there is no stable middle. Once you see decisioning as a layer rather than a feature, the question stops being which tool has the best journey builder and becomes where the decision lives and what it is allowed to see.
A simple example
Consider a customer who abandons a cart, opens the app an hour later, and is also part-way through a post-purchase onboarding flow from last week. Three systems could plausibly react. The email tool wants to send a cart reminder, the push tool wants to nudge the app session, and the onboarding flow wants to continue its sequence. Without a decisioning layer, all three fire, because each one only sees its own slice of the customer. With a decisioning layer, one engine holds the whole picture, suppresses two of the three, and lets the most valuable action through. Same data, very different experience on the other end.
The architecture view
Where decisioning lives. The difference is not the tools, it is where the decision sits.
You can see this split in the tools themselves. Adobe ships decisioning inside Journey Optimizer as a capability distinct from the journey canvas, while Braze grew from a channel-first Canvas and has been adding cross-channel arbitration on top of it. That is the useful lens when you evaluate a platform: not whether it has a journey builder, because they all do, but whether it gives you one place to own the decision and have every channel honour it, or whether it quietly leaves that arbitration to you.
The mistake I often see
The recurring error is confusing a journey builder with decisioning. A journey builder is a canvas for drawing flows, and almost every channel platform ships one. Teams see the canvas, assume they already have decisioning, and start drawing the same suppression and prioritisation logic into every journey. A year later the email canvas, the push canvas, and the SMS canvas each encode a slightly different version of do not contact this person more than twice a week, and nobody can say which one is correct. A journey builder executes a decision, but it is not the place the decision should be owned. When I audit a stack that feels busy yet behaves inconsistently, this is almost always what I find.
Go deeper
For how this plays out inside a real platform, the Field Notes on Braze show where a channel-native canvas ends and where shared logic has to begin. For the larger placement question of whether the engine belongs in the CDP or the CEP, the CDP–CEP architecture decision works through the trade.
This node sits next to two others in Architecture Literacy: what a CEP is and why it named the whole stack, and the real difference between batch and event-driven, both landing soon.