Optimize Planning Models Using the Planning Area
Performance in planning models is largely impacted by queries and planning actions. These two factors can be optimized to reduce processing time when working with large public versions.
By optimizing the planning area, you keep the data size manageable and can work on data that’s the most relevant to you. You can think of the planning area as a version’s data used for all planning actions, that you can filter out and refine for a private version. Its size may vary depending on the model settings. Optimizing the planning area is especially useful if you’re trying to limit the data size of a model with a large public version that’s not limited.
You can optimize the size of the planning area in the Model Preferences, under the Data and Performance tab. Click the toggle under the Optimize Recommended Planning Area section, and using the dedicated options, select whether you want to limit the planning area based on data locking, data access control and model privacy, or both. Note that for both options to be effective, data access control and data locking must be enabled and configured. For more information, see Configuring Data Locking and Set Up Data Access Control.
You can limit the size of the planning area either using data access control, data locking, or both. This corresponds to the recommended planning area, that decreases the size of private version size when you create it based on data access and data locking. Data access restrictions give you access to the data for which you have write access, while data locking restrictions give you access to the data regions that are unlocked. With the planning area, when you edit a public version, or create a private one, the application stores a reduced data snapshot but still shows locked data outside of that snapshot.
When using data access and/or data locking options, the application generates a recommended planning area based on the data access and data locks configuration. While using data access control works best when users have more read than write privileges, using data locking configuration is the most effective for model owners and users with administration privileges, or when most of the data is stored in locked data regions.
When working with a public version in a story, the planning area filters the data based on what data you have permission to edit. Only data that you have edit permissions for will be put into edit mode. When creating a private version, you have the option to only copy the recommended planning area to the private version. Data actions and multi actions only affect data within your planning area.
This example shows how a model with a recommended planning area based on data locks would appear in a table.
- This area is outside of the recommended planning area for this version. This data will not be put into edit mode on a public version, or be copied to a private version unless otherwise specified.
- This area is inside the recommended planning area. You can plan on this data in a table, or by running a data action or multi action.
The filter in a private version, or public edit, represents the planning area. Although you’re explicitly limiting the planning area using the filter, the application merges the public version’s data to display data outside of the filtered data region. In a myBudget private version for instance, if the filter is set to Region Germany, it’s processed as Region.ID not in (‘Germany’) in the Budget public version that’s mapped to myBudget. This way, data actions and multi actions are limited and contained within the filter and planning area, and the application provides better guidance in stories for planning actions. If a data action or multi action is outside the planning area, the application throws an error.
Having a small sized subset of data for a private version can speed up performance significantly. However, there are additional costs to consider when a private version has a defined planning area:
- Each query must process the negated filter for data that’s outside of the data region.
- Each query evaluates the filter to prevent data entry and planning actions for data that’s outside of the data region.
- Each data action and multi action must process the filter to be consistent with the planning area.
- Dimensions are treated independently so that filters like “(Product = Running Shoes and Time = 2020) or (Product = Tennis Shoes and Time = 2021)” are simplified to “Product in (Running Shoes, Tennis Shoes) and Time in (2020, 2021)”.
- Filters on dimensions are ignored if the number of filter values becomes too high (for example, after the hierarchies are unfolded).
The application marks cells that are (partially) outside of the planning area as not ready for input. In the above example only ‘Running Shoes’ is unrestricted by data locks. When the public version is set into edit mode or a private version is created based on the public version and the planning area is used, the planning area will be limited to ‘Running Shoes’, too. Other products like ‘Tennis Shoes’ will not be part of the planning area and thus not ready for input. Also, the common parent in the hierarchy, ‘Footwear’, will not allow input.
In this example, the planning area coincides with the data locks. But there are differences: You can choose to ignore data locks in the table. If the private version was created without the recommended planning area, you can then change values that are usually locked. However, you cannot publish these changes. If the private version was created with the recommended planning area, you cannot change these values, even if you choose to ignore the data locks. ‘Tennis Shoes’ is outside of the planning area and thus cannot be changed.
How the Planning Area Calculates Which Data you can Edit
These are the rules for calculating whether a cell is inside the planning area:
-
All dimensions that are in the filter of the planning area need to be on one of the axes or filtered to a (positive) list of members (exclude and range filters are not sufficient). If this condition is not met, the cells will not allow input because the query processing misses information to determine whether the cell is inside the planning area.
-
For a cell to allow input, all member combinations that may be aggregated into its value must be inside the planning area. This means, the dimensions used in the filter of the planning area need to obey the following:
-
For a dimension with a hierarchy on an axis, all descendants of the dimension member must be inside the planning area.
-
For a dimension without a hierarchy on an axis, the dimension members belonging to this cell must be inside the planning area.
-
For a dimension that is not on an axis, a filter must limit the members to a subset of the members inside the planning area.
-
Dimension attributes, that are filtered or on an axis, do not count as having the dimension itself filtered or on an axis. You need to filter the dimension additionally or put it on an axis in addition to the dimension attribute.
-
- Input on the following features won’t be allowed in any case if a planning area is used: Dynamic time filters and LOOKUP formulas if they operate on a dimension that is used in the filter of the planning area. These two features can reach out of the limits of the filters set on the table.
You can view the filter of the planning area in the Details section of the version in the Version Management panel.
Tips for Working with the Planning Area
The rules that determine whether a cell is inside the planning area can lead to situations in which cells no longer allow input, even though they would allow input without the planning area. For example, a cell of a public version that seems to allow data entries might not allow input once the version is put into edit mode. This is because the planning area is only applied when the edit mode is started.
Before starting the edit mode, it is not determined whether the edit mode or the copy to a private version will be done with or without planning area filters. Especially when the recommended planning area is based on data access control, this can lead to more limitations than without using a planning area. If you have DAC enabled on a dimension that is neither on an axis nor in a filter of a table, data entry and publishing may work without planning area. If the data is distributed in the right way, you might only need to change the member combinations that you have Write access to. When you enable the planning area based on data access control, however, the cells will not allow input anymore because the dimension is neither on an axis nor in the filter.
To avoid such situations, it is recommended to have all dimensions that are potentially used in the planning area filter on an axis or in a filter in your stories. You can influence which dimensions that includes by basing the recommended planning area either on data locks or on data access control or on both.