What’s going on with my business rule security?

Author: Mike Falconer

 

So, I was assisting a customer using Hyperion Planning on-premise when we were stuck with a peculiar problem. It started fairly normally: a user couldn’t see or launch the business rule attached to a form. “Quite the simple fix”, I hear you cry in contempt while looking for a new, better blog. I thought so too, snorting with derision as I worked through my standard checklist for such issues:

  • Rule attached to the form? Check
  • Security group has launch access to the rule? Check
  • User in the security group? Check
  • Security filters up to date? Check

Oh dear. All my standard checks came up empty. In desperation I turned to another cheap support trick, creating a user with similar access. Lo and behold, this test user was able to run the rule successfully. Colour me confused.

 

At this point I should give some background. The customer in question was running four separate security groups: UK, EU (presumably foreseeing Brexit), USA and Asia. The user was trying to access her EU rules, but they weren’t appearing for her. My test user had EU access and they were appearing correctly for me. Both users were in the appropriate EU Security group, with launch access to all of the EU business rules. What on earth is going wrong?

If you’d like a hint, here’s a redacted screenshot of their EU Business rule security:

Have you figured it out yet?

Here’s where it gets fun:

As any Hyperion newbie knows, the security groups in Shared Services work in a very simple way – if you are in two security groups, one with read access to a member and one with write access to a member, then you will receive the greater access i.e. write access to that member. Guess what – that logic is backwards for business rule security.

 

If you have a user in both the UK and EU groups, with launch access to UK and EU business rules respectively, and both groups have also specified No Launch access to the other group’s rules, then No Launch will overwrite Launch. This is the opposite of the way security works in the rest of the Hyperion suite, but it does surprisingly make some kind of sense.

 

After all – if you give a Planner Launch access to their own rules, that’s all they will see. There’s no point using No Launchunless you need to lock down certain rules when users will have access to combinations of both. But, in doing so, you will break the access for users who need access to multiple regions.

 

My conclusions, when working with business rules:

  • The Hierarchy is No Launch > Launch > No access granted
  • If you want users to run a rule, use Launch
  • If you want users to not run a rule, leave the access empty.
  • Don’t touch No Launch with a barge pole. Seriously.

 

Any different experiences using No Launch? Drop me a message!

Catch you next week,

Mike