What is a Decision Flow?

Most enterprise analysis is repetitive. The same five questions get asked every Monday, the same monthly review cycle runs across thirty stakeholders, the same quarterly pipeline check happens in every business unit. Without a Decision Flow concept, that work is rebuilt from scratch each time — either by a senior analyst rewriting the same SQL, or by a junior analyst copying last week’s spreadsheet and changing the dates.

Decision Flows compound that work. The first time you run the analysis takes 20 minutes via Catalyst’s conversational interface. You save the resulting flow with a name and a parameter list (region, time window, segment). From that moment, any authorized operator can run the same flow with a single click and updated parameters.

The structural payoff: institutional knowledge stops walking out the door when a senior analyst leaves. The flow is the artifact, the analyst is the author, the team is the beneficiary.

Every Decision Flow has the same four-part anatomy. Some flows have all four; many simpler flows skip the actions step.

1. Trigger. When does the flow run? Three common patterns: manual(an operator clicks “run” on demand), scheduled (every Monday at 8 AM), or event-driven (when an upstream metric crosses a threshold). Diwo Catalyst supports all three.
2. Steps. The ordered analytical tasks the flow performs. A retail merchandising flow might run: retrieve sales by region → compare to baseline → identify outlier categories → rank by dollar impact → generate AI briefing. The user defines the steps once via the conversational interface; the platform stores them.
3. Outputs.What the flow produces — typically a recommendation card, supporting charts and tables, an AI-authored briefing, and three AI-validated alternative strategies. The output is a decision package, not a single chart.
4. Actions. Optional outbound steps the flow takes after the recommendation is approved. Push the brief to Slack, email it to a stakeholder, file a ticket in the operational system, update a campaign audience in Mailchimp. The flow ends at the action, not at the chart.

Decision Flows sit alongside (not instead of) the existing analytical artifacts. Each has its place.

• Dashboard. A static view of metrics, refreshed on schedule. Read-only. Operator interprets what they see. Useful for monitoring; insufficient for decision-making at scale.
• Ad-hoc query.A one-off question against the warehouse. Useful for exploration. Ephemeral by design — the work doesn’t compound.
• Scheduled report.A pre-built deliverable emailed at a cadence. Solves the “same data every week” problem partially — the data refreshes, but the analysis is fixed and the recommendation is absent. Operator still has to interpret.
• Decision Flow. A parameterized, runnable procedure that produces a fresh recommendation each time, optionally pushes the action, and logs the decision to the audit trail. The flow improves over time as outcomes feed back into the model.

The right enterprise stack uses all four. Dashboards monitor; queries explore; reports communicate; flows decide.

The pattern is industry-agnostic; the specific flows are concrete.

• Retail. Weekly Markdown Review. Trigger: every Monday 8 AM. Steps: pull inventory turnover by category, compare to seasonal baseline, identify excess situations, rank by revenue at risk, propose markdown depths. Output: a ranked queue of markdown decisions. Action: push approved markdowns to the merchandising tool.
• CPG. Trade Promo Lift Check. Trigger: end of each promotion. Steps: retrieve actual lift, compare to forecast, decompose by retailer and SKU, score variance. Output: brief identifying which promotions to repeat, which to retire, which to redesign.
• Financial Services. Cardholder Activation Wave. Trigger: monthly. Steps: identify dormant cardholder segments, score propensity to activate, propose three campaign approaches (offer, channel mix, audience size). Output: ranked recommendations with dollar projections. Action: push approved audience to the marketing automation tool.
• Healthcare. No-Show Risk Alert. Trigger: event-driven (when weekly no-show rate exceeds threshold). Steps: identify affected clinics, decompose by appointment type, propose targeted reminder sequences. Output: prioritized intervention list. Action: push patient segment to the engagement platform.
• Operations. Supplier Risk Scan. Trigger: weekly. Steps: pull lead-time variance, supplier financial signals, delivery exceptions. Output: at-risk supplier list with proposed dual-source realignment. Action: ticket procurement.

In Diwo Catalyst, building a Decision Flow doesn’t require code. The conversational interface walks an analyst through the steps:

1. Start with a regular Catalyst conversation. Ask the business question in plain English; let the platform return the answer with charts and recommendations.
2. When the analysis is right, click “Save as Decision Flow.” Name the flow, identify which parameters should be adjustable (region, time window, segment), and set a trigger (manual, scheduled, event-driven).
3. Optionally configure outbound actions: email recipients, Slack channels, system-of-record pushes. Each is opt-in per flow.
4. Share the flow with the team. Permissioned by role capability flags — not every operator can edit every flow.

The first time the analyst builds the flow takes 20-30 minutes. Every subsequent run takes seconds. After a quarter of usage, a Catalyst tenant typically has 15-40 active Decision Flows, each running on its own cadence, collectively producing more decisions per week than the analytics team could ever produce manually.