Most commonly used folder structure

  • 11 January 2023
  • 0 replies
  • 26 views

Userlevel 2
Badge +1

 

When building applications, there are certain folders and structures we use in almost every use case application (read: not applicable to the Hub or specific Admin applications). Read this article to know more about general architecture on your workspace. This folder structure allows us to order the blocks intentionally, separate out the blocks that serve important functions, and maintain flexibility to add new blocks as the application scope and complexity evolves.

 

Pro tip: just like a nice cabernet sauvignon and an aged cheddar, this article pairs beautifully with our naming convention best practices

 

Here is an example of a Revenue Planning application which uses our recommended structure:

 

0YT8GzJ2UOPufsG-MgrE-dFM2Oyn4ZPfyiWZYaJ1mPxoy9PSHg1zegBJqHAwLzvZix2Zo5dhyOxSC-KpXr4ilr7gGujmuhrPEhxUKhX4yOHMMDVNoImmlPrmftxInteNexHplz6jLCgCRfe6SwkYbULdxiWx46oQZTm1vTeZ-pztmAWUgwMKsENTxLwDWw

 

Basic folders

 

The 0X folders seen in the example are those that you will usually find in any use-case application, so let’s take a deep dive into each:

 

00. Settings: this folder is meant to contain all the blocks that are used for settings in the application – i.e. any blocks created to configure/tailor the application or for technical purposes – like mapping metrics or variables metrics like the “Load Month”.

 

01. Dimensions: this folder will be used to keep all the dimensions that are specific to this application. Having this dimension folder appearing at the top makes it convenient to quickly find all of your application-specific dimensions as you’re modeling. 

 

02. Library: This is a folder we recommend creating to visualise the inflows and outflows metrics between our application and others in the workspace. It will usually contain both Push and Pull metrics, Push being sanitised versions of the end result metrics of our application which need to be shared with other applications, and Pull being the receiving blocks of other applications’ Push metrics. We like to name them with a prefix to indicate whether they are Push or Pull; for example: “Push_Name of the metric” or “Pull_Name of the metric.” Click here to read our article about why you should use Library folders

 

03. Assumptions: This is a dedicated folder for model assumptions that can be used when relevant, such as “Yearly Tax Rates (by Country)”, “Yearly Increase”, and “Month of Increase”. If a model requires more than a few assumptions, it can be clearer to keep them with the “themed” folder that will be used after (see below), but if you have a model with fewer assumptions, an assumptions-specific folder can help keep these to hand.

 

Data folders

 

In the 1X range, we usually create folders for data loads and checks to help consolidate and validate the data being used in your application.

 

10. Data Loads: all the transaction lists containing data coming from external sources can be stored in this folder as well as the metrics that we use to aggregate data from those transaction lists (we call them staging metrics).

 

11. Data Checks: metrics that are used to check the quality of the data or to fill missing mapping, run numbers checks and that might be displayed on board.

 

Themed Folders

 

In the 2X range and beyond, we will then have themed folders based on the calculation step of the model. For example, in a Revenue Planning application, we want to start by calculating the Pipeline Forecast and then compare it to the Sales Capacity Forecast. Our folder structure will look like this:

 

20. Pipeline Data: metrics aggregating relevant data from the transaction list in 10. Data Load

21. Pipeline Assumptions: metrics used to input or calculate assumptions used for the forecast calculation

22. Pipeline Forecast: forecast results metrics

 

We could apply the same structure on the following folders: 

 

30. Sales Capacity Data

31. Sales Capacity Assumptions

32. Sales Capacity Forecast

 

Alternatively, you might want to keep any transaction lists (previously mentioned in the 1X range) with the associated folders with an organisation like this one:

 

20. Pipeline Load 

21. Pipeline Data

22. Pipeline Assumptions

23. Pipeline Forecast

 

Or even like this, with the transaction list and the data metrics together in one folder:

 

30. Sales Capacity Load & Data

31. Sales Capacity Assumptions

32. Sales Capacity Forecast

 

As expected there are many ways to handle and arrange the basic folders in an application. There is no “right” way to do it, but if it’s relevant to your use case, try to get as close as possible of what has been presented in this article or like in the example below:

 

Workforce application Opex application
K6hUPpcgacnV3fcHHC8QkkCH9Zx5noXhzI8eFLAtm_aO6LM7A20gsp09LoULrNnRIvW7wBJTz0SvgxDQCs58gimWFZlpgKCQg9QA1L82OfJQK_wzmcrW8oTGVO4SjHYHwj-6tHSYFn1_aREPOp1bAFNicaTmyracdgAZoS---gyrhK6TEzj_NncCCBNuyg ztXF-aC9CTulM_UI2IctU4bW9XhOreHHHSxJHYSr-cAp1o2W9B9J6vmolgNWW9cRJcBN6YRJRm_w5P6m44HGEbYJDLtuhsB4OCiQUJ21H5Ll2BpF4JGqyNoquT9w1KXur0wAmRqvSp193KTVN3gEL2JmOYz8UI7xyEr3cc5oj7PNoVWUy2P3x5oriK_Oig

 

By structuring folders in this way, we can make sure that all our frequently referenced blocks are easily visible at the top (the 0X folders), and the rest of our blocks are organised thematically in an easy-to-navigate way. Don’t forget to read all about our approach to naming conventions to better understand why we name our folders this way, and how we name the blocks themselves, as well as other objects in your workspace.


0 replies

Be the first to reply!

Reply