Skip to main content
Skip table of contents

Hands-On Example: Defining Submodels

Modeling projects in Valsight often faces the challenge of decomposing a complex logic into the right submodels for the specific usecase. In this article, we share an example and walk through the considerations of the structure and associated dimensionality.

In general, before defining the submodel strucutre, you should have a clear idea who is going to use the model and the overall usecase. A model that is only used for simulation by a single person is easier to structure than a model that is suitable for a multi-user planning process.

In this article, we will outline the model structure for a model that is suitable for multi-user usage.

Proposed Submodel Structure

The proposed submodel structure - Arrows indicate the "has submodel" relationship, hence they define data access and not data flow (data flow = opposite directection of arrows)

Let's work through this from bottom to top, starting with the data sources.

Our recommendation is to connect data sources to only one model, as it makes the management and updating much easier in the long run. Data sources can even be configured to be attached to one model, which enforces that they are not used anywhere else.

The 400 Data model now simply "pulls the data in". All information that is used should be connected to a single node in the model. Typically you do simple data cleaning tasks such as mulitply with -1 or 1000 in this model layer. The data model often contains just a few not connected nodes. This will make it easier in the long run to understand which data is used where. In an ideal world, the "400 Data" model only contains actual (or factual) data, such as the last actuals, or - if you want to use a Forecast or Plan as basis for the simulation - then this. The important distinction between all other models is, that the "400 Data" model should not contain any datapoints in the future, it mearly defines the basis for the simulation.

The 300 Premises model is the first where we may see data about the future. It contains nodes that are used as drivers in all other models, such as an inflation rate. Here it is important, that all data is only brought into the simulation through assumptions in the scenario manager. You may, however, work with multiple data scenarios to include testdata, for meaningful data previews. With the example of our inflation: You would enter a 0% inflation in the data scenario and onlyset it to 2% in the scenario manager. You can, however, add a second data scenario, where you enter the 2% directly so that simulation on the data scenario produce meaningful output in the data preview. To facitlitate the planning process later on, each node in the premises model should have at least the "business model dimension" which basically is the Org or Business model dimension by which the 200 - Layer is split up.

The 20X Models use base data from the 400 and 300 models to define business model specific logic. They typically define how base data (no info about future) and premises (info about future) are combined to create a simulated outcome. Additional drivers that are only relevant for this business model can be modeled here. It is advisable to retain the Org dimension in this model, as it eases the combination in the next layer. Alternativly the data can be pulled into the next layer with the expand single functionality.

The 100 P&L model defines the entry point for our workspaces. It creates a combined view to allow us to access all data. Depending on your specific needs, this model can be either empty, or very simple, e.g. just combining revenues and costs from all different submodels.

The names and numbers used are not mandatory and only used to make the models a) sortable and b) clearer which models are on the same layer. You may add additional layers if it helps to structure your usecase. Many prefer, for example, to use multiple models in the premises layer to differentiate between different drivers.

Summary - Submodels

Model Layer



Dimensionality (minmal)

100 P&L

Combination of all specific business modells

Simulation Horizon

Time, Org, others

20x Business Models

Define Specific business logic

Simulation Horizon

Time, Org, others

300 Premises

Define Placeholders for generic drivers

Simulation Horizon

Time, Org, others

400 Data

Pull Data into the model

Base Year


Recommendations for interfaces between models, based on examples

Model Layer

Dimensionality (min)

Dimensionality typical Usecase


100 P&L

Time, Org




Time, Org

Revenue [ 2018, Business Unit A, 50 ; 2019, Business Unit A, 55 ; 2020, Business Unit A, 60 ; ....]

20x Business Models

Time, Org, Business Model specific Dimensions, for example



Market Growth

Time, Org

Inflation [ 2018, Business Unit A, 0 ; 2019, Business Unit A, 0 ; 2020, Business Unit A, 0 ; ....]

300 Premises

Time, Org and Dimensions valid for all Business Models, such as Countries


Revenue (Base)

Sold Volume (Base)

Time, Org

Revenue [ 2018, Business Unit A, Product X, 100]

400 Data

Time, Org, Technical Dimensions to select/filter/clean data

Data Layer

Excel Files


Usually time and Org

We include the Org level in each data layer, because it eases the implementation of data permission on this dimension later on

Implementing the Planning Process with Workspaces and Scenario Sharing

Adding data about upcoming projects and assumptions is done in the Workspace layer. Following the submodel structure from above, we define a workspace for the premises, one for each planning entity and one for the P&L view. The following table shows the association to the models

Model Layer



100 P&L

100 P&L

Core users


One Workspace for each model, or multiple per model.

If you, for example, have only one model for the product business, but still have multiple entities that enter planning data for products, you can create multiple workspaces per model. Access can be differentiated with workspace filters & data permissions.

Planning Users

300 Premises

300 Premises, one workspace to enter assumptions about premises.

Core users

Process Time

(1) Start of Planning Process

(2) Kickoff Data Entry in Planning Entities

(3) "Doing" of Data Entry, Parallel in the organization.

(4) Start of Consolidation Phase

(5) Discussions

Process Step

Defining Premises and Targets


Planning Entities


Consolidate Scenarios


Core user for planning process

Core user for planning process

Each Planning User

(1) Each Planning User, (2) Core user for planning process

Core user for planning process


  • Lock project

  • Define assumptions about basic premises on the Workspace WS300

  • Share the Scenario in the 300 Workspace

  • Include the shared scenario in each entities workspace via "Scenario assumptions"

  • In each entities Workspace (or business model specific workspace), enter the specific assumptions for one or many scenarios.

  1. In each entities Workspace, share the scenarios that should be available to the consolidated group view.

  2. In the 100 P&L Workspace, include all shared scenarios

  • Simulate each's business units scenarios

  • Perform simple changes of all underlying assumptions by adding Simulation line items as delta

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.