Not everyone in your organization should see every number. Hierarchy security lets you limit users to the companies, departments, regions, or accounts they're responsible for — and because the rule is applied to the data itself rather than to each report, it follows your numbers into the cubes, your Catalyst reports and dashboards, embedded Power BI, and Excel. This guide covers what it does, when to reach for it, and how to set it up without locking your team out along the way.
The essentials
If you read nothing else, read this. Everything that follows expands on these five points.
How it works
A hierarchy is how Catalyst organizes a dimension of your business — your chart of accounts, your legal entities, your sales regions, your product lines. Securing one turns it into an access control: instead of every user seeing every branch, each user sees only the branches their group has been granted.
The model is opt-in, and that single word explains most of its behavior. Nothing is visible by default, access is only ever added and never subtracted, and the grants live on groups rather than on individual people. Users inherit whatever their groups allow, so a controller who covers two entities simply belongs to both entity groups and sees the combined total.
The path from a user to a number looks like this:
Two details are worth internalizing early. First, Client Admins are exempt — users with Is Client Admin checked always see every secured hierarchy, which is why an admin testing their own login will never see the restriction working. Second, a grant on a node covers everything beneath it. Granting Midwest Region automatically covers every location added under it later, so granting high and letting inheritance do the work is the difference between a permission set that maintains itself and one you re-edit every month.
Nodes and leaves. Hierarchies are built from nodes (the parent levels that group and roll up data) and leaves (base-level records tied to your source system — individual GL accounts, entities, product IDs). You can secure at either level, but node-level grants are almost always the right call. See Mapping Hierarchies in Catalyst.
Where the restriction shows up
This is the part most teams underestimate, and it's the best argument for using hierarchy security rather than trying to control access report by report. Security is enforced on the data, not on the screen. You configure it once, and it travels with the numbers everywhere they're read.
One scoping note on Power BI. Hierarchy security is inherited by Power BI dashboards embedded within the Catalyst application. That's the supported path, and it's what makes the "configure once" promise hold. See Embedding Power BI Reports in Catalyst.
Which cubes this covers
Everything above describes the standard consolidated cubes — the Financial Tabular and Profitability Tabular cubes you'll find under Analysis > Data Cubes. For most organizations that's the whole picture, and you can skip to the next section.
If your organization also uses Smartload, it's worth knowing that Catalyst organizes data in three layers, and hierarchy security can reach further than the standard cubes:
The practical version: if a Smartload cube exposes a slice of data you've just restricted elsewhere, that restriction doesn't follow it by default. Adding the secured hierarchy to that cube's configuration is what closes the gap — a small change, but one that has to be made deliberately.
Not sure whether this applies to you? Most organizations don't manage their own Smartload area. If you only see a Data Cubes section on the Analysis page, everything above is already handled. If you also see a Smartload cubes section there and someone on your team manages those cube configurations, include the secured hierarchy when you configure them. If you'd like a hand — or you're not sure who owns that in your organization — reach out to EBM Support and we'll check it with you. Background reading: What is Smartload.
Navigation access and hierarchy access work together
Catalyst controls access in two separate layers, and confusing them is behind a good share of "the permissions aren't working" tickets. Navigation access determines whether a user can reach a section, tile, cube, or visualization at all — whether it appears in their menu. Hierarchy security determines what data appears once they're inside it.
In practice you almost always need both. Granting someone access to a secured hierarchy doesn't help if they were never given navigation access to the cube or visualization that displays it — they simply won't see the report to open. Equally, navigation access to a dashboard without a hierarchy grant produces a report that opens to nothing. Neither symptom means the feature is broken; each means one of the two layers is missing.
Both are configured on the same group, which makes them easy to set together — navigation permissions on the Set Navigation Permissions step, data permissions on the Hierarchy Permissions tab. When you build a group, decide both at once rather than treating them as separate projects.
Plan before you enable it
Enabling security is a single checkbox, and it is immediate and total. The most common bad experience with this feature isn't a misconfiguration — it's a well-configured hierarchy secured on a Tuesday morning before the groups existed.
Read this first. The moment you enable security on a hierarchy, every non-admin user loses access to that hierarchy's data — not just the people you meant to restrict. Reports go blank, filters come up empty, and dashboards look broken. Access returns only as you grant it to groups and refresh the cube. Build your groups before you enable security, or be ready to grant access immediately after.
The sequence that avoids all of this:
Decide what you're restricting, and to whom. One sentence is enough — "regional managers should only see their own region." That sentence names both the hierarchy and the groups.
Sketch the groups on paper first. A two-column list — group name, and the node it should reach — takes ten minutes and saves an afternoon of rework. Aim for a handful of durable groups, not one per person.
Build and populate the groups. Create every group and add its users before the hierarchy is secured. Groups can exist perfectly happily without any hierarchy permissions attached.
Tell your team, ideally 48 hours ahead. A short note naming the change, the window, and who to contact turns "the system is broken" tickets into "yes, that's expected today." Pick an off-peak window and stay available for the hour after.
Secure, grant, refresh, and verify in one sitting. Treat these four as a single task. Don't enable security and come back to the grants tomorrow.
Common use cases
If you're weighing whether this is worth setting up, it helps to see the shape of the problem it solves. Five patterns cover most of what we see in practice.
Sales reps and regional managers
Each VP gets a territory P&L without the Southeast rep benchmarking commission against the Northwest team. One group per territory, each granted its region node. You build one territory dashboard instead of eight, and new accounts landing under an existing region are covered automatically.
Multi-entity groups and partial ownership
Site controllers own their entity; only corporate finance sees the consolidated roll-up. One group per entity plus a corporate group at the top node. This is the pattern that gets asked for during audits and after acquisitions, and it handles JV or minority-owned entities cleanly.
Department budget owners
Department heads run their own budget-vs-actual reviews instead of emailing Finance for a spreadsheet, while the Marketing director still can't read payroll detail for Operations. Usually the highest-leverage use case — it's what makes self-service reporting safe for non-finance managers.
Product line and brand teams
Brand managers get SKU-level margin for their own lines, and cross-brand comparisons stay a conversation you have on purpose. New SKUs mapped under an existing category node inherit the permission, so a fast-moving catalog doesn't generate permission work.
External parties — auditors, lenders, franchisees
An auditor needs one entity; a franchisee needs their own location. Historically that meant exporting a scrubbed workbook and emailing it. A narrowly scoped group with a grant on exactly one node replaces that — and because the filter lives in the cube, the restriction survives the export. Removing access at the end of the engagement is one group removal, not a hunt for distributed spreadsheets.
Restricting by scenario instead? If the goal is to hide a specific budget version or forecast rather than a slice of the org, that's a separate feature — see Managing Scenario-Level Security in Catalyst. It's disabled by default and enabled by EBM Support on request.
Set it up
Six steps, and the first three are ordinary user administration you may already do routinely. Give yourself about 30 minutes for a first-time setup, plus 15–30 minutes at the end for the refresh to propagate. You'll need Client Admin rights. Work through the cards in order — the sequence matters more than it looks.
Steps 4 through 6 belong together. The moment step 4 is saved, only Client Admins can see that hierarchy's data. Don't stop there and return to the grants tomorrow — finish the grants and the refresh in the same sitting.
More detail on group mechanics lives in Manage Users with Groups in Catalyst, and on hierarchy settings generally in Managing and Adding Hierarchies.
What each step looks like
Refreshing the cube
Hierarchy security is enforced inside the cube, which means your changes sit dormant until it rebuilds. This is the single most common reason a correctly configured setup appears not to work, and the reason a user might see correct data in Catalyst but stale data in an embedded dashboard.
If you're setting up several groups or securing more than one hierarchy, finish all of it first and refresh once at the end. Each rebuild costs time, and refreshing mid-configuration just pushes a half-finished permission state out to your users.
You don't need to refresh anything on the Power BI side — embedded dashboards pick up the change with the cube. If Catalyst looks right and an embedded report doesn't, the cube refresh is almost always the missing piece. See Troubleshooting Catalyst Power BI Integration.
Verify it worked
Don't take the configuration screen's word for it. Impersonation shows you Catalyst exactly as one of your users sees it, and it takes about two minutes.
Open the user list. Click your profile icon in the upper-right corner and select Impersonate to reach the Manage Users screen.
Pick a non-admin test user. Find them in the list, click the three-dot menu beside their name, and choose Impersonate. Their name appearing in the top-right profile area confirms you're in.
Check more than one surface. Look at a dashboard, a report, the Planning page, and any embedded Power BI visualization. Confirm they see what they should — and that a restricted branch is genuinely absent from filters and drop-downs.
Exit, then repeat per group. End the session from the top-right menu and spot-check one user from each group. Five minutes here is cheaper than a week of confused tickets.
While impersonating, you can't make changes — it's a read-only view by design. If something looks wrong, clear your browser cache by clicking the Catalyst logo in the top left and reload the page before concluding the permissions are broken.
Best practices
Troubleshooting
Nearly every issue with hierarchy security traces back to one of four things: an unrefreshed cube, a missing group grant, a missing navigation permission, or a Client Admin doing the testing.
Common questions
Related articles
Manage Users with Groups
Creating groups, adding members, and the permission tabs in detail.
Managing Users and Permissions
User records, Client Admin, and how impersonation works.
Managing and Adding Hierarchies
Hierarchy types, settings, and where Enable Security lives.
Mapping Hierarchies in Catalyst
Nodes vs. leaves, and why mapping determines what a grant covers.
Managing Scenario-Level Security
Restricting budget and forecast versions instead of org structure.
Embedding Power BI Reports
Navigation access and row-level security for embedded dashboards.
Troubleshooting Power BI Integration
When security looks right in Catalyst but wrong in a dashboard.
Cube Overview
How cube-connected Excel files read the data you've secured.
Catalyst Glossary
Definitions for hierarchy, cube, node, leaf, and more.
What is Smartload
The L1, L2, and L3 data layers and how custom cubes are built.
Cube Configuration Guide
Building perspectives — and why hiding a field isn't the same as securing it.
Adding and Setting Up New Users
Creating the accounts that go into your security groups.
In short: build your groups first, secure the hierarchy, grant each group the node it needs, set navigation access alongside it, refresh the cube, and verify by impersonating a real user. Because the rule is enforced in the cube rather than in each report, you configure it once and it holds everywhere — Catalyst, your reports, embedded Power BI, and Excel. If anything looks wrong after a change, check the cube refresh before anything else. Still stuck? Submit a request and our Support team will help.
Comments
0 comments
Article is closed for comments.