If you have ever had an issue with security before, chances are you have used the ‘Refresh Security’ function on your IBM Planning Analytics (TM1) server. It is usually the first thing someone suggests when they learn your security settings have not updated as expected, and you are not sure why that is.

The ‘Refresh Security’ function is only appropriate if there are rules on security objects – Cube security, Dimension security, or Element security. Running this process forces the rules to regenerate the internal structures used for the TM1 API functions that govern security. This means that without running the security refresh the security objects may show one thing, but the internal structures may still be stuck with outdated security.

An example would be if your TM1 application includes a form of workflow where the workflow status determines which security groups have access to a cube. Suppose that status changes from “In Process” to “Submitted” (granting access to the approving manager) but ‘Refresh Security’ is not run. Then the TM1 rule that governs cube security will not update appropriately and the user will not have the access they expect, even though the }CubeSecurity cube will show that they can access the cube.

There are two ways to refresh security:

  1. An administrator can log in to Architect, right click on TM1 instance and go to Security -> Refresh Security.
  2. A TM1 Turbo Integrator (TI) process can be written to refresh security using the SECURITYREFRESH() function. This can be placed in a process of its own or placed in the EPILOG of a TI process that causes updates to objects that would impact security rules.

If running ‘Refresh Security’ is causing issues due to frequency or length, there is one clear solution: No Rule Security.

The go-to solution to this problem is to create security via TI processes rather than rules wherever possible. If the security rules are changing and requiring a security refresh on a regular basis, there is a good chance security needs to be re-thought. This is certainly true if security refreshes are having to occur based on user inputs or changes and in the middle of the busy work day.

This does not mean all TM1 rule driven security is necessarily bad. Security that does not change over time or updates on a nightly, weekly, or monthly basis make more sense as rules. These would just require that a process be added after these updates to refresh the security, although it is worth asking the question why it cannot be done via a TI process.

It is also worth noting that cell security does not require a security refresh! Cell security almost always requires rule security since cell security is governed by a cell security cube which is usually too large to populate via TI processes. Since cell security does not require feeders or a security refresh this is a situation where security rules are the usually the only option.