DimensionElementPrincipleName – What The Heck Is It?

I recently had an issue with a TM1 TI Process that did not want to load data where the data source was using an Alias.  I’ve never had a problem with using an Alias before, but there is always a first for everything.  To get around the problem, I changed that variable to “Other” and created a new variable using the following TI function to change the Alias to the Principle Name.  At that point, the data would finally load.  That function is DimensionElementPrincipleName

What is DimensionElementPrincipalName?

This is a TM1 TurboIntegrator function, valid only in TurboIntegrator processes.

This function returns the principal name of an element or element alias.

TurboIntegrator must use principal element names when updating dimensions; element aliases cannot be used. This function is therefore useful for determining principal element names while attempting to update a dimension when only element aliases are available to the TurboIntegrator process.


DimensionElementPrincipleName ( DimName, ElName )

TM1 Implementation Methodology for Success

All Cognos TM1 implementations require a strategy to deliver an appropriate reporting solution. This is the plan that will ensure that each business user will have access to all the TM1 data they need, in the most usable format and in a timely manner. This plan must be based upon environmental configurations, user experience levels, as well as time and budget constraints. The plan should outline a strategy that will meet the business requirements during acceptance testing, initial deployment to production, as well for a conceivable period of time into the future.

A proven, best practice strategy for reporting is to Solve, then Evolve.

Screen Shot 2013-09-16 at 9.16.53 PM

With this approach, the application’s “core statement” needs are first identified and then “solved for”. These are not individual analyst support reports or ad hoc data queries; rather, only those reports required to complete (close) and/or monitor a business process (P&L, Income Statement, Balance Sheet, etc.). The reports may also include critical KPI’s or KRI’s. They are usually fixed in format and require a standardized styling format. They may be parameter-driven; for example “Income Statement” by period, or by country. These reports lend themselves best to being deployed using TM1 Websheets.

Once the standard “book of business” statement reports have been delivered, ancillary statistical reporting needs can then be considered. These reporting needs are usually much more individualized and narrowly focused. These would include very specific views of data based upon specific business questions. They can include “check” and “reconciliation” views of data. These reports are almost always solvable using TM1 compiled cube views that are accessible using TM1 Web and the TM1 CubeViewer. The TM1 CubeViewer will also allow users to perform various filtering and drilling operations on the data that each cube view displays.

Finally, as the application matures and the level of user experience increases, it may be beneficial to evolve the reporting solution by considering the deployment of TM1 Perspectives to specific members of the business user community. These users will usually be the “power users” of the group with responsibility for performing more in depth, advanced or complicated analysis and reporting. Because of the nature of TM1 Perspectives, it is recommended that care be taken before offering Perspectives as a user option. Performance and concurrency are the 2 main areas that may have a detrimental effect on both the Perspectives user as well as the overall TM1 application.  TM1 provides a layer of security that you can apply so that these “power users” can create TM1 WebSheets for input and reporting purposes, yet are locked out from actually creating/editing TM1 objects (i.e., Cubes, Dimensions, etc).

Bulk Absorption and Configuration

From a pure architectural perspective, what is sometimes referred to as “bulk uploading”, sometimes is (mistakenly) considered to be part of reporting or included in the data consumption component of the application.  Loading and/or updating data is part of the applications absorption or configurations components and should be handled with a best practice approach of leveraging TM1 TurboIntegrator scripts and/or active Websheets (designed based upon user and environmental requirements and constraints).


It is important to keep the implementation of the reporting solution (the consumption layer) separate and distinct from the key value add (the processing) of the TM1 application being deployed. From an architectural perspective, the manner of consuming the application’s data may (and most likely) will evolve:

  • As user needs and levels of expertise change, the method for consuming data may need to change
  • Other reporting tools and/or technologies may be considered in the future (for example, Cognos Insight or Cognos BI) which will change the method for data consumption
  • Organizational changes may require additional or different analysis and reporting; and, therefore, may change the method of data consumption.

By solving the initial reporting requirements, you are able to provide a timely deliverable that will be a gateway to user acceptance and product satisfaction, as well as management appreciation of the ROI for this software investment.   Keep in mind too, that properly training users goes a long way.  The more they understand the usefulness of TM1 and how it can fulfill their needs, the better they will assist in providing requirements for future evolution.