When it comes to Hyperion security, there are quite a few things you can mess up. You probably already have a list of things you should be doing, or “best practices.” In this blog post, we’ll cover what you shouldn’t do — the “worst practices” — when it comes to Hyperion security.
Applying security directly to a user (other than the admin)
This is one of those “work smart, not hard” situations. If you apply security directly to the user, you’re losing all those settings if that employee leaves your organization. When a replacement arrives, you’ll once again have to figure out all their permissions and security settings. There’s really no reason for all of that work that’s probably keeping you from a few other pressing tasks.
What you need to do is use groups. Make a group for every type of position — it’ll be much easier to query and maintain. When someone inevitably leaves, their replacement can easily be dropped into the group and — voila! — they have the proper permissions.
Having too many or too few groups
Now that we’ve clarified that you should be using groups, you need to know how to use them the right way. We’ve seen some companies with thousands of groups because they didn’t write up their requirements and build their security structure properly.
You should design the makeup of your groups around your organization’s structure or, more specifically, the structure of your finance department. The easiest way to do this is starting from the bottom up, so you’ll want to make a group for READ access. All the finance employees should be able to read all the numbers, but you’ll want to limit who can write. From there you’ll create a WRITE group that has a portion of the members in the READ group.
Applying role and access to every.single.group
When you need to separate segments of your users into basic users versus managers/power users, it’s a bad idea to apply both role (READ/WRITE) and access (by entity, by region, by cost center, etc.) to a group. Instead, create access groups (by entity, by region, by cost center, etc.) as usual and then create a few groups based on user types. Each user will belong to an access group and a role group. When the forecast cycle opens, all role groups may be set to WRITE. After the deadline, switch the basic users to READ while your managers/power users keep WRITE access. All users can still see data, but managers are the only ones able to make changes.
Provisioning multiple applications to your groups
Provisioning multiple applications to a few groups may seem like a quick way to get your user base access to all systems necessary, but, as applications are added or phased out, this may cause heartburn down the road — and leave room for a messy trail of “what have I done here?”
Having groups provisioned to a single application is the cleanest way to go, and your maintenance will be much easier to manage — you’ll thank yourself later!
Not keeping Hyperion security documentation up to date
When the system is new, nice, and shiny, it’s easy to take the documentation from your implementation partner, check off the box as complete, and file it away. You know what groups (native or active directory) have been set up and what provisioning is applied to where. You know how to add users where it’s appropriate.
Then, the application development group builds a new application with slightly different security requirements. While you are implementing those changes, don’t skip the documentation step. Your successors will thank you when they get the call from audit for the security documentation on who has access and how it is managed.
For more infrastructure tips, download the eBook...
