Get FP&A best practices, research reports, and more delivered to your inbox.
Yes — every serious FP&A platform supports role-based access controls. The useful question is how deep they go. Role-level permissions (viewer, editor, admin) are universal and mostly interchangeable across vendors. What actually differs is whether permissions reach the data itself: a specific table, a specific dimension, one department’s salary lines. That distinction decides whether you can safely give a department head access to the platform at all.
There are three layers worth testing, and most evaluations only test the first. A platform that offers roles but not data-level restrictions will push you into managing sensitive data by excluding people from the tool — which is how finance teams end up emailing spreadsheets again.
Bottom line: ask for a live demonstration of three things: a role, a group, and a restriction on one specific table containing compensation data. Then confirm the restriction still holds in exports and in the Excel or Google Sheets add-in. That last check is where most permission models leak.
Do FP&A tools support role-based access controls?
They do, and the model is well established outside finance software. NIST’s role-based access control project defines the pattern most vendors implement: permissions attach to roles, users are assigned to roles, and access is granted through role membership rather than user by user. It scales because you administer a handful of roles instead of hundreds of individual grants.
In FP&A the standard implementation is three global roles. Viewers can open dashboards and reports but not change anything. Editors can build and modify models, forecasts, and budgets. Admins manage users, permissions, and integrations. This covers the basic case — and stops well short of the cases finance teams actually worry about, which are almost always about specific data rather than specific actions.
The three layers of FP&A permissions
Layers one and two are near-universal in the category; layer three is the differentiator, and the one to test hardest.
The three layers compose. A user can be an editor globally, a member of the Sales Finance group, and still be blocked from the compensation table — that combination is what lets you open the platform widely without opening the data widely.
Can FP&A tools restrict access to salary data?
Yes, if the platform supports data-level permissions. Compensation data usually enters FP&A through an HRIS or payroll integration and lands in a dedicated table or dimension. Restricting it means setting permissions on that object so only named roles or groups can read it, while everyone else works with aggregates — total departmental cost, average cost per head, budget versus actual at the cost-center level — that carry no person-level detail.
This is the most common real requirement in FP&A permissioning and the one that trips up the most evaluations. It is also genuinely difficult, because headcount planning inherently needs compensation figures. The workable pattern is to separate the aggregate from the detail:
- Department heads see their own team’s total cost, open roles, and budget variance — not individual salaries.
- FP&A analysts model at the role and band level, using midpoints or planned rates rather than actual individual pay.
- HR and the CFO see person-level detail.
- Everyone works from the same underlying table, with permissions doing the separating rather than a second copy of the data.
That last point matters more than it sounds. The alternative — maintaining a sanitized copy for wider distribution — creates two sources of truth, and the sanitized copy is always slightly stale. Permissions on one table avoid the reconciliation problem entirely. For how this plays out in a planning workflow, see AI FP&A tools for headcount planning and the headcount planning solution.
Watch out: restricting the table is not sufficient on its own. Check whether a restricted user can reach the same figures through a report someone else built, a scheduled export, or a connected spreadsheet. Permission models enforced at the document layer commonly fail all three; models enforced at the data layer do not.
What are the standard FP&A roles?
Vendors name these differently, but five roles cover almost every real finance org. Mapping your people onto this set before you look at software makes the permission comparison much faster.
Viewer
Reads dashboards and reports, changes nothing. This is the right role for most executives and department heads outside finance, and it is usually the cheapest seat class — worth checking, because seat pricing by role is common and viewer seats determine how widely you can share.
Contributor
Enters or submits data for their own area without being able to restructure models — a department head entering next year’s hiring plan, or a regional manager submitting a forecast. Not every platform has a distinct contributor role, and its absence is what forces teams into collecting inputs by spreadsheet and re-keying them.
Editor
Builds and modifies models, forecasts, and budgets. This is the core FP&A analyst role. Editors normally need broad read access to financial data and, in most policies, aggregate-only access to compensation detail.
Approver
Reviews and signs off on submissions before they enter the plan of record. Where this exists as a real role rather than a convention, it is usually tied to a workflow engine — and it is the feature enterprise-oriented platforms lead with.
Admin
Manages users, permissions, integrations, and hierarchies. Admin is the role to ration: it typically carries the ability to see everything and to change the permission model itself. Two or three admins is healthy for a mid-market team; a dozen is a finding waiting to happen.
How many roles do you actually need?
Fewer than the first draft of the matrix suggests. The common mistake is creating a role per job title, which produces twenty roles that nobody maintains and access that drifts within a quarter. Roles should correspond to distinct permission needs, not to org-chart positions — if two titles need the same access, they share a role.
A practical test: if you cannot describe what makes a role different from its nearest neighbour in one sentence about data access, merge them. Most mid-market finance teams run well on five to seven roles plus group membership for team-scoped access, and that combination is materially easier to review each quarter than a long tail of bespoke grants.
Where permission models leak
Four leak points account for nearly every real-world incident, and all four are testable in a trial.
- The spreadsheet add-in. A platform can enforce restrictions perfectly in its web interface and still let a connected workbook query the restricted table, because the add-in authenticates differently. Test the restriction through the add-in specifically.
- Exports and scheduled reports. A CSV export or an emailed scheduled report can carry data the recipient cannot open interactively.
- Inherited dashboards. If a dashboard built by an admin renders with the builder’s permissions rather than the viewer’s, every viewer sees admin-level data.
- Stale access after offboarding. A user removed from the platform may retain a working cached connection, or an API token, until it is explicitly revoked. This is what SCIM provisioning is for.
None of these are exotic. They are the four things worth an hour of a trial, because each one is invisible in a security questionnaire and obvious in a test. If a vendor cannot demonstrate the add-in case in particular, treat data-level permissions as unproven regardless of what the datasheet says.
What will an auditor ask about permissions?
Access control is a standard part of a SOC 2 examination, and the questions are predictable. The AICPA’s SOC framework covers logical access under its trust services criteria, and in practice an auditor will want to see four things: a documented permission policy, evidence that access is granted through an approval process, evidence that it is removed on offboarding, and a periodic review showing someone actually checked.
The reason this matters for software selection is that three of the four are easier to produce when the platform records them. A queryable log of permission changes turns the review from an afternoon of screenshots into a report. If your FP&A platform cannot show who granted access to what and when, that evidence has to come from somewhere else.
How do users get access in the first place?
Permissions decide what a user can reach; provisioning decides whether they have an account at all, and the two need to be connected. The pattern to look for is single sign-on plus directory sync: SSO so authentication runs through your identity provider, and SCIM so account creation, group membership, and deactivation follow automatically when someone joins, moves team, or leaves.
Without directory sync, offboarding becomes a manual checklist item in a different team’s process, which is exactly the kind of control that passes an audit on paper and fails in practice. With it, removing someone from the identity provider removes their FP&A access.
RBAC or attribute-based access control?
Role-based access control grants permissions through role membership. Attribute-based access control (ABAC) evaluates attributes at request time — a user’s department, an entity, a data classification — and decides dynamically. ABAC is more expressive and considerably more work to administer.
For most mid-market finance teams, role-based control with data-level restrictions and group membership is the right answer; it covers the real requirements without a policy engine to maintain. ABAC starts to earn its complexity in large multi-entity groups where access genuinely depends on a combination of attributes — a controller who should see their own legal entity only, across every account, with the rule holding automatically as entities are added. If that is your situation, see multi-entity consolidation software, where entity-scoped access is a core requirement rather than an edge case.
How the major FP&A platforms compare on permissions
Role and group permissions are effectively standard; the meaningful comparison is data-level depth and whether it survives the spreadsheet layer.
Capabilities and packaging shift, and several vendors gate SSO or granular permissions behind higher tiers — confirm which tier includes what before signing. Our FP&A software pricing guide covers how tiering works across the category as of August 2026.
How Aleph handles role-based access
Aleph implements all three layers. Global permissions cover viewers, editors, and admins. Group-level permissions let you tag users into teams and manage access collectively. Data-level permissions apply to any data table or dimension, which is the layer that makes compensation restrictions workable.
- Identity: Auth0-backed identity management with suspicious-IP throttling and brute-force protection; Google and Microsoft SSO by default; SAML for providers like Okta.
- Provisioning: SCIM directory sync, so users are provisioned and deprovisioned from your identity provider and permissions follow group membership.
- Enforced at the data layer: restrictions hold in the web app and through the Excel and Google Sheets add-ins, so a connected workbook cannot pull a table the user cannot open.
- Recorded: permission changes and data access appear in the account audit log, and version control keeps every prior state of a model restorable.
- Certified: SOC 1 Type II and SOC 2 Type II, AES-256 at rest, TLS in transit, hosted on Google Cloud Platform, with on-premise hosting available.
Because Aleph is spreadsheet-native by design, the data-layer enforcement is the load-bearing detail rather than a footnote — the whole point is that analysts keep working in Excel and Google Sheets while permissions still apply. Full detail is on the security page. Finance teams at BigID, Zapier, and Envoy run on this model.
A permission matrix worth copying
Before configuring anything, write the matrix. Roles down the side, data domains across the top, and one of three values in each cell: full detail, aggregates only, or no access. A workable mid-market default looks like this — adjust the sensitive rows to your own policy.
The row that generates the most debate is the FP&A analyst: aggregates-only for compensation is achievable, and it is the setting that makes wider platform access safe.
Once the matrix exists, governance becomes configuration rather than judgment. It also becomes reviewable — you can hand it to an auditor, and you can re-check it each quarter against who actually has access. The broader framework this fits into is covered in FP&A data governance, and the change-tracking half in audit trails in FP&A.
Get FP&A best practices, research reports, and more delivered to your inbox.
