TM1 Forum

We are deploying a fairly simple TM1 model and I'm trying to get security for elements and users working correctly. For example assume that we have accounts grouped as follows and a list of products that need to have unique security:

SALES EXPENSES => Writable by Sales group 1 and 2, no access for Ops groups
OPS EXPENSES => Writable by Ops group 1 and 2, no access for Sales groups
PRODUCTS => Writable by Sales groups 1 and 2, but should only see products specific to group 1 or 2 when working on that view.

The standard security works fine for about 90% of the end users using cube level and element level security as most are assigned only to a "Sales" or "Ops" group, and of course they only see the expenses as shown above, and if assigned to only one sales group, only see the products for that group. However, a number of end users either are end users assigned to multiple sales groups (and see products for all sales groups for which they are members) and others have responsibility for both Sales and Ops expenses, which means that they see both types of expenses when viewing the data for either type of group. Clearly, this creates confusion for end users.

I believe the solution lies in developing a dynamic subset for our expenses and products, but really don't know where to start. What I'm thinking of doing is building a cube that contains the cost centers (same as groups for security assignment) and expenses as an example and populating it with data if the expense applies to that group, and believe that could be used to build a dynamic subset.

If anyone can provide me some guidance, sample code, or steer me in the right direction, it would be appreciated.

Mike

Have you looked into cell level security on the cube(s) in question? Your scenario is one of the situations where they are appropriate.

tomok wrote:Have you looked into cell level security on the cube(s) in question? Your scenario is one of the situations where they are appropriate.

I'll give this a go. Thanks for the reply.

tomok wrote:Have you looked into cell level security on the cube(s) in question? Your scenario is one of the situations where they are appropriate.

So I've implemented your suggestion using a cell level security cube for a cube where a test user is given access to two different cost centers that have access to a different range of elements in the cube. When opening up the cube, the view looks as follows:

When accessing one cost center, the user sees this:



When accessing the other cost center, it looks as follows:



In addition, I thought that assigning element level security would allow me to "hide" the elements to which the end user was not supposed to see when looking at a particular cost center, with security set up as follows:



While this security set up does prevent end users from making inappropriate entries or seeing data, is it not possible to hide the elements that the end user should not see or am I simply doing something wrong?

Thanks in advance!
Mike

mmckimson wrote: In addition, I thought that assigning element level security would allow me to "hide" the elements to which the end user was not supposed to see when looking at a particular cost center, with security set up as follows:

Element level security WILL result in a user seeing only those elements of a particular dimension that they have access to. Cell level security is not the same thing as element level security as you are not limiting elements of a single dimension, you are limiting specific dimension element combinations in a cube. Unfortunately, TM1 cannot hide those combinations that you do not have access to because you could have a view with a combination of rows and columns where you have access to certain combinations and not others. If TM1 limited either the rows or columns you wouldn't be able to see those combinations that were valid. If you think about it for a moment you will understand why.