Managing security is a balancing act and even more so in Hyperion Planning. On the one hand, the administrator must satisfy management’s requirements that only users who need to see the data will have access to the data. On the other hand, the administrator must find a way to ensure the security model can be managed and maintained.

These two requirements don’t often go hand in hand.

Management, of course, wants to implement security on every area of the planning cube. After all, it is natural for management to demand strict secrecy in a planning application. Planning data is extremely sensitive since it describes the future of the company. Management is correct to require complex security rules and segregation of information.

Managing multiple groups along multiple dimensions can be a daunting task. Keeping track of which users go in what group along with the applicable filters requires careful consideration and special attention to details. It is an administrator’s nightmare. Administrators often have to rely on spreadsheets to maintain master lists of users, groups, filters, roles, etc.

To help make this task easier, here are a few hints on what does and doesn’t work:

• Nesting groups within groups – This method can save a lot of time when setting up the groups. However, it is hard to maintain because individual users do not appear directly in the group. For example, to see which access a given users has, the admin must open several groups until the answer is found.

• ExportSecurity.cmd and ImportSecurity.cmd – Managing filters in Planning by using the security features in Workspace is cumbersome and slow. Using the ImportSecurity.cmd is easy, quick and efficient. In addition, the source file used to upload the security information can be used for back-up and documentation.

• File system in Shared Services – Using this utility to make changes to Groups and Users provides the same benefits described in the above item.

• Define groups that mimic the dimension structure – It is tempting to create a group for every function or team. Using this approach will lead to having a very large number of groups. Mimicking the dimension structure allows the administrator to take advantage of the ‘intersection’ concept of multi dimensional databases. For example, in an environment were security is defined along the cost center, entity, account, version and scenario dimensions, the user gets access based on the intersection of the cost center, entity, account, version and scenario groups.

• ‘Super Groups’ – A super group is a group that has all users in it. You can use these groups to control access to the Planning dimensions such as account, version and scenario. Since the Planning dimensions must have security enabled, they may also share the same access for all users. For example, all users must be able to write to the active scenario and version. In this case, use the ‘Super Group’ to give everyone access to these dimensions.

• Consistent naming conventions – For clarity and ease of use, it is important to maintain a consistent naming convention. For example [planning designation][Application name][dimension identifier]_[functional description], PLN_ESTCUBE_CC_ITSupprt.

• Group descriptions – Make sure to write a clear description of the group when it is set up. This will help later for back-up and documentation.

• Demonstrate the impact of security filters – Show management the impact of increasing the number of security filters. Making the impact available to management may pay dividends in the future. It will help management to come up with reasonable levels of access.

Creating and managing security filters are not easy tasks. However, using the above tips, the job can be made less daunting.