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, though it pays to be precise about what is being centralised, because four different things hide inside the word. There is the policy, meaning the rules about frequency, eligibility and suppression. There is the definition of the audiences and signals those rules run on. There is arbitration, the act of picking one action when several qualify. And there is execution, the sending itself. Policy and definitions genuinely have to be single-owner, because two copies of a frequency rule are two rules the moment somebody edits one. Execution is distributed by nature and should be. Arbitration is the interesting case: it can sit centrally, or it can sit per channel provided every channel arbitrates against the same centrally owned policy. A stack that centralises the policy and distributes the execution is a stable middle, and a common one. 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 what a CEP is, the layer that usually executes the choice, and batch vs event-driven, which decides what gets to trigger one. For whether the engine needs its own product or can live inside one you already run, see layer or product.