As business analytics coaches, it is our passion to talk about things that make your job easier. Today we are going to talk about best practices in naming conventions in TM1 and application management. Naming conventions in TM1 are effective if and when adopted early. Once you have an established environment, it is difficult to go and update and/or change names of objects. It may sound trivial to change or update names but it’s most definitely not. As you may know, changing the names of well-established objects in a TM1 Ecosystem requires unravelling multiple layers of objects that are interconnected. Starting early and sticking to a naming standard will help in future activities like error resolution, optimizing the environment, adding capabilities and finally the most important of all, documentation & knowledge transfer.

Choosing a naming convention requires all developers involved agreeing on the naming convention. Each object in the application has to be named using the same method. In order to take a systematic approach to this, what we do is take the lowest level in objects and go up from there.

Elements – This is a good place to start because it is the lowest level object in the application. It is advisable to choose the element principal names as a digit code and straight from the source. If the digit code is a description, use that as an Alias. If the description is not unique, amount all the elements then concatenate it with the digit code and make it unique. There are many other ways to make things unique. You need the description to be unique because you can’t have a duplicate Alias on TM1. Refrain from using special characters in element names. If your metadata source has special characters, replace them or omit them during the dimension build during the ETL process.

Subsets – Keep subsets to the minimum. We have noticed with many clients, that there are duplicate subsets meaning there are subsets that have the same elements in them. Keep the subset list clean by deleting duplicates. Use uniform names for dynamic subsets. Try to be descriptive in the name without making the name too long. Prefix dynamic by labeling them as such. Most subsets should be created on the fly in a turbo integrator process. This limits the amount of subsets to a great deal.

Dimensions – If a dimension is specific to a cube, name the dimension with the cube name in it. For example, if an account dimension is for the P&L cube, using something like PL_Account is a good idea. That way all the P&L specific dimensions are listed together in the dimension list.

Cubes – This should follow the same pattern as the dimensions. For example, cubes should be prefixed with the type of cube it is. (PL_XXXX, BS_XXXX etc.)

TI Process and Chores – Special attention should be paid to these objects since they are looked for when a specific activity has to be performed on the application. These activities can span from anything related to maintain dimensions and loading data to extracting data. Having a good naming regiment here is essential for yourself and your predecessors. A good method is to prefix the name with the action being performed. For example, a dimension action can be prefixed with DIM_, a data Load can be prefixed with LOAD_.  If you have a large application with a mix of different types of cubes, you can prefix the process names with the name of the cube. (P&L_Load, P&L_Dim_Account) This kind of naming convention ensures objects are clustered together and makes life easier for everyone.

Following a structured approach that is agreed upon by all developers in the application is how you keep a sustainable TM1 ecosystem. Please feel free to reach out to us at Sales@LodestarSolutions.com for details on naming conventions in TM1 or any other items.