Configuring Planning Views, Data Sources, and Handling Save/Refresh in Detail
Learn how planning views are built and configured in the Excel Add-In, how data sources and filters shape what planners see, and how the save and refresh mechanics work under the hood, including common performance and conflict scenarios.
Explanation
Moving beyond basic usage, intermediate consultants need to understand how planning views are actually constructed and tuned in the Excel Add-In, since this configuration work is frequently done by IBP consultants and power users rather than end planners. A planning view definition combines several elements: the planning level (which master data attributes define the granularity, e.g., Product-Location-Week), the key figures to display (a mix of input, calculated, and aggregated key figures from the planning model), a filter (restricting to specific products, customers, planning versions, or time horizons), and layout options (row/column arrangement, frozen panes, time bucket profile such as weekly or monthly). When a planner opens a saved planning view, the add-in issues a data retrieval request to the IBP backend. The backend resolves the filter against master data, aggregates or reads key figure values from the in-memory planning area (often HANA-based), and returns a result set that the add-in renders into the Excel grid using its own custom ribbon-driven rendering engine, not native Excel formulas for the data cells themselves. Time series key figures appear as columns per time bucket, and the add-in manages formatting like decimal places, unit conversion, and color-coded alerts inline. Data sources matter: a planning view can pull from a single planning area or, in some model designs, reference data from multiple time profiles (e.g., weekly buckets for near-term supply and monthly buckets for long-term demand) within the same sheet using separate planning view areas. Consultants configuring these views must be careful about performance: wide time horizons combined with many key figures and low-level detail (e.g., Product-Location-Customer-Day) can generate very large result sets, causing slow refresh times or Excel memory issues. A common tuning technique is to default views to higher aggregation levels (e.g., Product-Location-Month) for initial review, letting planners drill into detail only where needed, rather than always rendering full granularity. The save mechanism deserves particular attention. When a planner edits an input-enabled key figure cell and issues Save, the add-in sends only the changed cells (delta) back to the backend, not the entire view, which is important for performance. The backend then applies any configured disaggregation logic if the edit was made at an aggregated level (e.g., editing a monthly total might disaggregate proportionally across weeks or based on a profile), and recalculates any dependent calculated key figures. If two planners have overlapping planning views and one saves changes, the other planner's already-open Excel session does not automatically update — they must manually refresh to see the change, which can create the illusion of stale or conflicting data during concurrent planning cycles. There is no automatic locking of cells across users in most configurations, so organizational discipline (assigning ownership by planning level, or using time-boxed planning cycles) is typically used to avoid overwrite conflicts rather than relying on system-level locking. Troubleshooting refresh and save issues typically starts with verifying: the add-in version compatibility with the tenant, network connectivity to the tenant URL, whether the key figure is genuinely input-enabled in the model, whether the planner has authorization for the relevant planning level/filter, and whether background operators (like disaggregation jobs) have completed. Consultants should also be aware that very large save operations can time out, and it is generally better to save more frequently in smaller batches during heavy editing sessions.
Real project scenario
During an S&OP implementation, a consultant configured a default planning view at Product-Location-Month granularity for the monthly consensus meeting, but planners kept manually drilling to weekly detail, causing timeouts during the live meeting due to the large result set across all regions. The consultant restructured the view into two versions — a lightweight monthly summary view for the meeting and a separate detailed weekly view for offline pre-meeting analysis — which resolved the performance complaints without removing planner flexibility.
Common mistakes
• Building planning views at maximum granularity by default, causing slow refresh and Excel performance issues for planners. • Assuming other planners' Excel sessions auto-refresh when someone else saves changes to the same planning view. • Not verifying authorization/filter scope before troubleshooting 'missing data' issues, when the real cause is a security restriction. • Editing an aggregated key figure without understanding the configured disaggregation logic, leading to unexpected distribution of values across time buckets. • Trying to save enormous multi-thousand-row edits in one operation instead of batching saves, risking timeouts.
Best practices
• Default planning views to higher aggregation levels and offer separate detailed views for drill-down analysis. • Educate planners that manual refresh is required to see other users' saved changes; consider process-level coordination for concurrent edits. • Confirm key figure input-enablement and disaggregation configuration before assuming a save/display issue is a technical defect. • Encourage incremental saves during long editing sessions rather than one large save at the end. • Regularly review planning view definitions as data volumes grow, since views that performed well initially can degrade as master data expands.
Interview angle
Interviews at this level often test understanding of the delta-save mechanism, the lack of automatic cross-session refresh, and how planning view granularity choices trade off between planner flexibility and system performance — candidates should be able to describe a real tuning decision they made or would make.