TM1 lint is a very basic lint tool whose task is to flag "dangerous" TM1 rules.
For now it is only checking for aliases in rules.

Indeed, if an alias is changed or deleted, any rule based on that alias will stop working without any warning from the system. The values will remain in place until the cube or its rules gets reloaded but you will only get a "silent" warning in the messages log after reloading the cube.

Monitor rules and processes

Changing a rule or process in TM1 does not show up in the logs.
That is fine as long as you are the only Power User able to tinker with these objects.
Unfortunately, it can get out of hand pretty quickly as more power users join the party and make changes that might impact other departments data.
So here goes a simple way to report changes.

The idea is to compare the current files on the production server with a backup from the previous day.

You will need:

The fallacy of blb files

TM1 system files with the blb extension, incorrectly referenced as "cube formatting" files (admin guide p.35) are actually "rule formatting" files for the "standard" rules editor (prior to 9.1).
The rules editor actually displays the contents of the .blb if there is one, otherwise it defaults to the .rux.
Unfortunately things can go wrong, and the .blb file gets desynchronised from the actual .rux or just go blank.

Dynamic formatting

It is possible to preformat dynamic slices by using the Edit Element Formats button in the subset editor. However that formatting is static and will not apply to new elements of a slowly changing dimension. Also it takes a long time to load/save when you try to apply it to more than a few dozen elements.

As an example, we will demonstrate how to dynamically alternate row colors in a TM1 report for a Customer dimension.


Dimension elements containing a single quote character (') require a double quote to be interpreted correctly by the rules engine.
Example: ['department's'] -> ['department''s']

One could use aliases without single quote characters too, however the rule would break if anything were to happen to these aliases. So it is best practice not to use single quote characters in your elements in the first place and if you really need them, then use the double quote in the rules.