Conclusion

Creating a cube and loading CSV data using a visual process gives you a powerful foundation for integrated planning, reporting, and scenario analysis.

By structuring your visual process workflow into clear stages—of cube design, creation of hierarchies, data transformation, and value insertion—you will be able to automate complex data preparation tasks with confidence.

This approach improves both data accuracy and analytical depth. And it enables your organisation to respond faster as business conditions shift and change. All that becomes possible because you can turn raw transactional data into meaningful, multi-dimensional insights using MODLR visual processes. 

Want to learn more?

• Watch Other Visual Process Videos from MODLR
  • Visual Process Overview- A MODLR Visual Process Tutorial
  • How to Use a Forex API to load Exchange Rates into a Cube - A MODLR Visual Process Tutorial
  • How to Load CSV into Cube - A MODLR Visual Process Tutorial
  • How to Sync an S3 Directory - MODLR - Visual Process Tutorial
  • How to Archive a Cube Slice to a CSV - MODLR - Visual Process Tutorial
• Check out our Related Q&A 

  Visual Process and Related FAQS

  MODLR’s visual processes make it easy for you to automate your data tasks such as building cubes, loading CSV files, and preparing data for reporting. By using simple step-by-step workflows, you will be able to quickly create structured analytical models, automatically update your dimensions while ensuring that your data is ready for accurate analysis and decision-making.

  What is a visual process in MODLR?

  A visual process is a simple, step-by-step workflow that enables you to automate data tasks such as creating data cubes, loading CSV files into them, or transforming data. Visual processes use connected nodes instead of complex coding which makes them easier to create, understand and maintain.

  Why should I review my CSV file first before building the process?

  Looking at your CSV first helps you understand how your data cube should be structured. You can quickly identify which fields will become dimensions and which will become measures, which saves time and avoids mistakes later.

  Why do we use dimension builder nodes?

  Dimension builder nodes help create hierarchy elements automatically from your data. This means new products, departments, or scenarios can be added without manual updates whenever new data is loaded.

  Why is it important to convert date formats during data loading?

  Dates in source files often use different formats from your cube’s time dimension. Converting them ensures the data matches correctly, so reports group numbers accurately by month or year.

  How do cube update nodes work in a visual process?

  Cube update nodes take values from each row in your file and place them into the correct location in the cube. They use dimension keys like time, product, and department to make sure every value is stored in the right context.

  How can I check if the data load worked properly?

  After running the process, you can open a workview or dashboard to review the cube. If you see the expected hierarchies and measures displayed correctly, it confirms that the data was loaded successfully.

  What are data cubes?

  Data cubes are structured data models that store information across multiple dimensions like time, product, region, or scenario. Storing data in cubes let you analyse it from different angles instead of looking at data in a simple list. This makes it easier to spot trends, and understand performance and relationships.

  For details, check out our article: What Are Data Cubes? Why MODLR Uses Them Instead of Tables

  Why does MODLR use data cubes instead of tables?

  MODLR uses data cubes rather than tables because cubes are better suited for planning, forecasting, and multi-dimensional analysis. Cubes support faster calculations, flexible reporting, and easier scenario comparisons. These can be difficult to achieve using the traditional flat tables alone.

  For details, check out our article: What Are Data Cubes? Why MODLR Uses Them Instead of Tables

  What Is Inside-Out Reporting in MODLR?

  MODLR’s Inside-out Reporting is a way of creating reports directly from a structured data model compared to the traditional way of building reports separately in spreadsheets or business intelligence (BI) tools. With this approach, the numbers always come from a single trusted source, which makes analysis more consistent, flexible, and reliable for both planning and decision-making.

• Video Transcript of How to Build a Sales Cube - A MODLR Visual Process Tutorial

  Video Transcript

  In this tutorial, we walk you through how to create a visual process that builds a sales cube and loads data into it from a CSV file. We will create the cube structure first and then build dimensions from the CSV data, and finally insert the numeric values into the cube.

  Before building the process, it is useful to review the CSV file that will be loaded into the cube. A preview of the file shows that each row represents a sales record with several attributes. These include fields such as SKU, product name, brand, department, scenario, units, and other related columns. By looking at the structure of the source data first, we can decide how the cube should be organised.

  For example, the Department column will become one cube dimension, while the scenario column will form another. Product-related fields such as SKU and product name can be used to construct the product dimension. Numeric columns including units, price, cost, and discount will become the measures that will be stored within the cube. Understanding the source data before building the cube helps us ensure that both the cube structure and the loading process are designed correctly.

  To begin building the visual process, we first add a sequence node. This allows us to split the process into multiple stages that run in order and keeps the visual process easier to read and maintain. 

  In this example, we use one step to create the cube structure and another step to load the CSV data.

  In the first step, we build the cube structure. We start by adding a dimension to create multiple node  to define the core dimensions that structure our cube. Based on the CSV data we looked at earlier we create the dimensions for Product, Department and Scenario.

  Next, we add a dimension create node to define a dedicated measure dimension. We name this dimension Sales Measures and set the type to measure. It becomes a dedicated dimension that can store numeric values.

  After creating the measure dimension, we add a dimension builder node and name it Create Measure Elements. This step defines the individual measure elements that will exist inside the sales measures dimension. 

  Inside the dimension instructions editor, we define the elements  under the default hierarchy. Here each element represents a metric that will later be stored in the cube. For example, we can use the following metrics from our CSV: Units, Price, Cost price, and Discount.

  These elements will later be populated once we insert the values from the CSV data. 

  With the dimensions in place, we add a cube create node to define the cube itself and specify which dimensions make up the cube structure. 

  We will name the cube as Sales. Next we add the dimensions that will form its axes. These include Time, Scenario, Department, Product, and Sales Measures. Once this node runs, the Sales cube will be created and ready to receive data from the CSV file in the next step of the process. 

  After the cube structure has been created, we move on to loading data from the CSV file. To do so, we add a CSV reader node in the second stage of the sequence. 

  In this example, we select the sales data.csv file. Once the CSV reader is configured, it will  read the file and trigger the process row-level output (once) for each row in the CSV. 

  Next we connect the process row execution port from the CSV reader into another sequence node to keep the next two steps organised. 

  Before inserting values into the cube, it is necessary to ensure that all dimension elements referenced in the CSV actually exist. To achieve this, we add a dimension builder node.

  Let us first focus on the Product dimension. Within the instructions editor, we define the strucructure of the product hiuerarchy.. Here we can dynamically reference values from the CSV column names. 

  In this example, we create a hierarchy called All Products by Brand. Brand elements are created under an All Brands parent. Products are ground under their respective brand and each product element is created using the values from the SKU column. Each product element is also given a readable alias using the product name column. We can also define a default hierarchy where all products appear under a single All Products element.

  Next, we add another dimension builder node for our Scenario dimension. Inside the dimension instructions editor, we define a very  simple structure. All scenario elements are created under the default hierarchy using values from the scenario column in the CSV.

  Next we add another dimension builder node to make the Department dimension. Inside the dimension instructions editor, we define another simple hierarchy, for departments,. Under the default hierarchy we create a parent element named All Departments and generate department elements beneath it using values from the department column in the CSV. 

  Once the dimensions are prepared, we need to insert data into the sales cube. 

  However, the CSV contains a date column formatted as day, month, and year, while the elements in our time dimension use a different format. To align the data and make sure the data matches the existing time dimension elements, we can convert the CSV date into the correct format using a map transform node. Inside the  modification section of the transform row node, we create a transformation for  the date field using a modeler formula. This formula reads the date value from the CSV row, interprets it correctly, using the original day, month, year format used by our time dimension and convert it into the year-month format required by our time dimension.

  With the row data prepared, we can begin inserting values into the cube by adding a cube update node. The first step is to insert the Units measure into the cube. For the value key we enter units. This tells the node which column from the row should be written into the cube. We then set the measure element to units, which determines which elements in the Sales Measures Dimension will store the value. 

  Next, we need to define the element keys that determine the exact location where the value will be stored in the cube. 

  The transformed date value is used for the Time dimension; the scenario column for the Scenario dimension; the department column for the Department dimension; and the SKU column for the Product dimension. Together, these keys uniquely identify and define the intersection at which the measure value will be written.

  Finally we repeat the same pattern for the remaining measures such as Price, Cost, and Discount. In each case, only the value key and target measure element change.

  Once all nodes are connected, the process is ready to run. When executed, the workflow reads each row from the CSV file, creates any missing dimension elements, converts the date into the correct time format, and inserts the measure values into the Sales cube.

  After the process completes, we create a workview to confirm that the data has been successfully loaded into the cube. In the workview, we can see the Sales cube displayed with rows showing the product hierarchy grouped by brand and product. The columns display the sales measures, including Units, Price, Cost, and Discount. This confirms that the CSV data has been correctly loaded into the cube and is now available for analysis and reporting.

• To explore this feature, you can book a demo today.