Configuring Alerts, Thresholds, and Exception Workflows in Control Tower
Learn how Control Tower alerts are built from alert categories, thresholds, and key figures, how they surface in the app, and how to troubleshoot missing or incorrect alerts in a production IBP tenant.
Explanation
Control Tower's core value is turning planning data into actionable exceptions. Instead of planners scanning every product-location combination, alerts highlight only the situations that breach a defined tolerance, such as a forecast error above a percentage, a supply shortfall against demand, or inventory falling below safety stock. Understanding how alerts are assembled is essential because a misconfigured alert either floods planners with noise or, worse, silently hides real problems. An alert in Control Tower is typically built from three components: an alert category (the business condition being monitored, such as late supply or demand-supply mismatch), a threshold or condition (a numeric or percentage boundary that triggers the alert), and a scope (the planning area, time horizon, and organizational filter the alert applies to). These are configured in the alert configuration app or embedded within the app's settings depending on the IBP version and planning area setup. Thresholds are usually expressed relative to a key figure already defined in the planning model, so the alert configuration depends entirely on having accurate, well-maintained key figures upstream. If a key figure calculation is wrong or stale, the alert built on top of it will be wrong too, even though the alert configuration itself is correct - this is one of the most common sources of confusion during troubleshooting. Alerts are evaluated during scheduled batch jobs or on-demand recalculations, not continuously in real time. This means there is a data latency window between when an underlying planning value changes and when the corresponding alert reflects that change. In practice, teams often run alert recalculation jobs right after the main supply or demand planning run completes, chained as a sequential job or operator, so alerts are fresh when planners start their day. If this sequencing is broken - for example, the alert job runs before the supply plan finishes - planners will see alerts based on outdated data, which erodes trust in the tool. Exception workflows extend basic alerting by allowing planners to acknowledge, comment on, or route an alert to another role. This is valuable in S&OP cycles where an alert needs sign-off or escalation, such as a large demand-supply gap that requires a decision from a supply planning manager rather than the demand planner who first sees it. Workflow routing typically relies on role-based views and case IDs rather than a generic workflow engine, so the design should stay simple: too many hand-off steps make the tool slower than a direct conversation. From a design perspective, the biggest judgment call is threshold calibration. Thresholds set too tight generate alert fatigue - planners start ignoring the app because most alerts are trivial. Thresholds set too loose let real problems slip through. The best practice is to start with conservative thresholds validated against at least one full planning cycle of historical data, then tune based on planner feedback and the false-positive rate observed over the first few weeks of go-live. Attribute-based scoping (by product family, region, or planning level) also matters: without proper scoping, alerts can double-count or apply to aggregate levels that don't map cleanly to a specific action owner. Troubleshooting missing alerts usually starts by verifying three things in order: whether the underlying key figure has current data, whether the alert job actually ran and completed successfully, and whether the alert's scope filter matches the planner's assigned view. Most "the alert never showed up" tickets resolve to one of these three causes rather than a genuine bug.
Real project scenario
A consumer goods client rolled out Control Tower for their S&OP process, configuring alerts for demand-supply imbalance greater than 15% and for late supply commitments beyond the promised delivery week. In the first two weeks, planners complained the dashboard showed dozens of alerts every morning for products with negligible volume, making it hard to spot the handful of alerts that actually mattered for high-runner SKUs. The IBP team resolved this by adding a minimum volume filter to the alert scope and switching from a flat percentage threshold to a tiered threshold that combined percentage deviation with an absolute unit floor, so low-volume noise no longer triggered alerts. They also discovered the alert recalculation job was scheduled independently of the supply planning run, causing a one-day lag; rescheduling it as the final step in the nightly operator chain fixed the freshness problem.
Common mistakes
ā¢ Setting a single global threshold for all products regardless of volume, causing alert fatigue on low-volume SKUs and desensitization to real high-volume issues ā¢ Scheduling the alert recalculation job independently of the upstream planning runs, resulting in alerts based on stale data ā¢ Assuming an alert configuration change takes effect immediately without rerunning the recalculation job, then reporting a false 'bug' ā¢ Building alert scope filters that don't match any planner's assigned view, so alerts exist in the system but no one ever sees them ā¢ Overusing exception workflow hand-offs for minor alerts, adding process overhead instead of speeding up resolution ā¢ Not validating thresholds against at least one historical planning cycle before go-live, leading to thresholds that are miscalibrated from day one
Best practices
ā¢ Chain alert recalculation as the final step after supply, demand, and inventory planning runs complete, not as an independent schedule ā¢ Combine percentage-based thresholds with absolute volume floors to avoid noise on low-volume products ā¢ Validate threshold settings against at least one full historical planning cycle before go-live ā¢ Scope alerts explicitly to match planner role-based views, and test visibility from each role's login, not just the admin view ā¢ Keep exception workflow hand-offs minimal; reserve escalation routing for alerts that genuinely require cross-functional decisions ā¢ Review alert volume and false-positive rate after the first few weeks live and retune thresholds based on planner feedback
Interview angle
Interviewers assess whether you understand that Control Tower alerts are only as good as the key figures and job scheduling behind them, not just UI configuration. Be ready to explain the alert category-threshold-scope structure, describe how alert freshness depends on batch job sequencing, and walk through a realistic threshold-tuning story showing you can balance signal versus noise. Strong candidates also mention verifying alert visibility against role-based views, since a common real-world defect is alerts existing but not being visible to the intended planner.