Note: The new permissions model is being rolled out gradually through H2 2026. If the screens described here don't match what you see, your organization hasn't been migrated yet and the previous model still applies. Your Customer Success Manager can confirm your organization's status.

Overview

This article answers the questions we hear most often about the new Datarails permissions model. It is a companion to New Permissions: Roles & Permissions Overview, Data Access Management, and User Management, which cover the model in full.

Permissions are a one-time setup, not ongoing maintenance. Once a user's access is defined correctly — by cost center, region, scenario, or whatever matches how your business is organized — it should not need revisiting unless your organization restructures or that person changes role. If you find yourself adjusting the same person's permissions repeatedly, their access is scoped to the wrong thing. Question 5 explains how to correct it.

How access works: three rules

Most questions below come back to the same three rules. Understanding them resolves the majority of permission issues without further reading.

• 1. Your role sets the ceiling. Element access grants the permission. Your system role (Viewer, Collaborator, Manager, Admin, Super Admin) determines the maximum access you are eligible to hold. It does not grant access to any specific table, Filebox, dashboard, or report — each of those must also be shared with you. Both have to be satisfied before an action succeeds.
• 2. Tables control data. Elements control functionality. Access to a dashboard, report space, Filebox, or workflow determines what you can do with it. Access to a table determines what data you see — everywhere it appears, in every report, dashboard, Excel function, KPI, and AI Agent. Granting one never grants the other.
• 3. Only Super Admins are automatically shared on everything. Every other role, including Admin, sees only what they created or were explicitly shared on.

Quick answers

If you are troubleshooting a specific symptom, start here.

What changed

1. What actually changed for existing users when the new permissions rolled out?

Two things changed.

Admins are no longer automatically shared on everything. Previously, Admin access was effectively blanket access. Now an Admin has full access to elements they created or were explicitly granted, and only Super Admins are auto-shared across the whole organization and cannot be removed from any element.

Table-level permissions now exist. There was no concept of access to a table before, so nothing was taken away — but actions that touch a table's structure (data mappers, lookups, custom columns) now require Owner access on that table, and it has to be granted.

Your existing data visibility was preserved through the migration: permission filters were generated automatically so that nobody gained or lost sight of data on day one. What needs your attention is who holds Owner on each table, and replacing the migrated filters with ones that match how your business is organized (see question 5).

This is a one-time exercise. Once table ownership and Viewer filters are set correctly, you no longer need to keep sharing individual Fileboxes - and permissions should only need revisiting if your organization restructures or someone changes role.

2. What can Contributors do now?

You might see: a user editing and saving table fields when they shouldn't be able to, or rolling a forecast you didn't expect them to reach.

The old Contributor role has been split in two, so people get only the access their job needs:

• Collaborator — budget submitters and department contributors. Upload data, submit inputs, view and edit Fileboxes and report spaces shared with them. Cannot create tables, build dashboards, or manage permissions.
• Manager — FP&A analysts and data owners. Create and manage tables, dashboards, reports and storyboards; handle mapping and integrations; manage permissions on elements they own or are shared on.

If someone has more access than you intend, check their role first — a person who should be a Collaborator may still be set as a Manager. Change it from their profile in Members & Groups; it takes effect immediately.

3. What's the difference between the "Viewer" role and "Viewer" access on a table?

Datarails uses "Viewer" for two different things:

• Viewer as a system role — the user's overall account type. They can view and download elements shared with them, cannot upload or submit, and have no Workspace access. This is the ceiling on everything they can do.
• Viewer as an access level on a table — the user can see that table's data in any output they have access to, but cannot change the table or grant access to others. The alternative on tables is Owner; there is no Editor level for tables.

These are independent. Someone with the Admin role can hold only Viewer access on a given table — which is the situation in question 4. In the other direction, only the Manager, Admin, and Super Admin roles can be granted Owner on a table at all.

To see the full picture for any person, open their profile from Members & Groups: it lists every element they can reach and at what level.

Tables and ownership

4. I'm an Admin — why can't I edit our tables, data mappers, or lookups any more?

You might see: "Owner permission is required", "Owner permission for this table is required to map a file box to it", or a table greyed out telling you that you have Viewer permissions.

Your role hasn't been downgraded, and no access has been taken away. Table-level permissions are new — previously there was no such thing as access to a table, so nothing has been revoked. What's changed is that this access now has to be granted deliberately, to the right people.

Tables have two access levels: Viewer and Owner. Editing a table, publishing a data mapper, adding a custom column, or editing a lookup all require Owner access on that specific table. Your system role (Manager, Admin, Super Admin) determines whether you're eligible to hold Owner access; it doesn't grant it automatically.

To fix it: first check who currently owns the table. If there's an owner, ask them — or a Super Admin — to go to Setup → Tables → the three dots beside the table → Share data, and change your access from Viewer to Owner.

Worth knowing: owning a Filebox is not the same as owning the table it's mapped to. If you can open a data mapper but can't publish your changes, it's the table permission you're missing.

Data visibility

5. A colleague sees zeros or blanks when they refresh, but the data is definitely there

You might see: data appearing as zero when refreshing the financials, DR.GET returning no data, certain cells returning a nil value, or specific months and entities missing for one person but not another.

This is a permission filter on the table, not a data problem. A permission filter restricts which rows of a table a user can see. It applies to every output built from that table — reports, dashboards, Excel functions, KPIs — and when a formula asks for data outside the filter it returns zero or blank rather than an error, which is why it reads as missing data.

Why this is happening now

When your organization moved to the new model, we generated permission filters automatically so that nobody gained or lost data access on day one. Where a user previously had access to only some of the Fileboxes mapped to a table, their filter was built from that list of Fileboxes.

Those migrated filters are deliberately frozen — they are not maintained as Fileboxes change, and they aren't meant to be. They exist only to preserve the access you had. The intended next step is to replace them with a filter that reflects how your business is actually organized — by cost center, region, entity, or scenario. Once you do that, the filter keeps working as new Fileboxes and scenarios are added, and you shouldn't need to revisit that user's permissions again.

How to replace a migrated filter

1. Go to Members & Groups and click the user's name.
2. Open Element-level permissions and select the table.
3. Click Edit Permission Filter.
4. Replace the Filebox-based values with the dimension that matches the user's remit — for example Cost Center = "X" and Scenario = "Budget" for a budget owner.
5. Save. It takes effect immediately.

Adding the one missing Filebox will unblock the person today, but it leaves the filter needing attention again next time. Replacing it is the one-time fix.

Also worth checking: some users may not need a filter at all. If a user can already see every Filebox mapped to the table, the filter can simply be removed — and some of those users should arguably be table Owners rather than filtered Viewers.

Two mechanics to be aware of:

• If a user gets access to the same table from more than one group, the filters combine with AND — they see only rows matching every condition.
• A filter can have Block Drill-Down enabled, which shows totals but not the rows behind them.

6. How do I let someone see only part of the data in a table?

Use a permission filter. It restricts a user to specific values of a dimension — Department, Region, Entity, Cost Center, Scenario, or any dimension in your table — and applies everywhere that table's data appears.

The user must hold Viewer access on that table. Permission filters apply to Viewers only - a table Owner always sees all the data mapped to the table, and a filter cannot be applied to them. If you raise someone from Viewer to Owner on a table, any filter they had on it is removed. To restrict what someone sees, they need to be a Viewer on that table.

1. Go to Members & Groups and click the user's name.
2. Open Element-level permissions and select the table.
3. Click Edit Permission Filter.
4. Choose the dimension and the allowed values.
5. Save — effective immediately.

Filtered users won't see restricted values anywhere: not in reports, not in dashboard dropdowns, not in drill-downs. Metrics are recalculated on only their permitted rows, so they see a correct total for their slice rather than a company total with rows hidden.

To stop them seeing row-level detail entirely, enable Block Drill-Down in the same settings. Restrictions on more than one dimension combine with AND.

Sharing and visibility

7. I shared a report or dashboard, but the person still can't see the data in it

You might see: a recipient who received a share notification but can't find the element, a report that opens with no numbers, or a widget reading "No Permission".

Separate two things: whether someone can open an element, and what data they see inside it.

Opening the element is controlled by that element's own permissions — sharing the dashboard, report, or report space. The data inside it comes from the table, and is controlled by the user's table access and permission filter. Fileboxes are not part of this chain: you can give someone data access without giving them access to any Filebox at all.

So if a colleague can open a dashboard but sees no numbers — or sees some months and not others — the element is shared correctly and the gap is in their table access or their permission filter. See question 5.

Note that Datarails won't prompt you to grant table access when you share an output. That's deliberate: the assumption is that table permissions have already been set correctly for each person, so a budget owner who is scoped to their own cost center will simply see their own cost center in whatever you share with them.

One separate case: if the recipient has the Viewer role, they have no access to the Workspace and can't browse to a report there. Add the report to a Report Space under Reporting → My Reports and share the report space with them. This is not a change — Viewers have always needed a report space to reach a report.

8. Why can't my user see the Filebox?

Seeing a Filebox and seeing its data are now two different things.

• Data access is managed entirely at the table level. A user with table access will see that table's data in reports, dashboards, and Excel outputs whether or not they can see any Filebox.
• Filebox access governs what you can do to the Filebox itself — upload files, manage versions, submit data, lock or archive it.

The three combinations:

So a user can legitimately have access to a Filebox's data through a permission filter and still not see the Filebox in the Workspace. That's the system working as intended, not a permission error.

The reverse also catches people out: a Collaborator can submit data they cannot read back. Uploading to a Filebox does not grant visibility of the resulting numbers in any report. If a department contributor needs to see their own submission reflected back, they also need access to the table.

If someone genuinely needs to work with the Filebox — to upload or submit — they need Filebox access and a role above Viewer, since Viewers have no Workspace access at all.

This is also a useful control: if a user only needs the numbers, share the data and leave the Fileboxes out. Fewer people in the Fileboxes means fewer chances of someone changing the wrong thing.

Managing users and groups

9. How do I add a new user, copy someone's access, or handle someone leaving?

To add a user: go to Members & Groups → Invite Users, enter their email, choose a role, then click Next to reach Set Permissions, where you have three options:

• Assign to groups — they inherit each group's access.
• Copy from an existing member — same group memberships and element access as someone already set up. The fastest way to mirror a colleague, for example when covering a role.
• Set manually — configure element access individually.

Role limits: an Admin can invite users and assign roles up to and including Admin. Only a Super Admin can assign the Super Admin role.

When someone leaves: use Deactivate rather than Remove if they might return — it revokes access immediately but preserves their permissions for restoration. Remove is permanent.

Deactivating also frees the license, which is how to handle a replacement when you have no spare seats: deactivate the outgoing user, then invite the replacement and copy their permissions.

10. Why can't I add or remove people from a group?

Only Super Admins can create groups or manage group membership. Admins can invite users, edit roles, and deactivate users, but group management is Super Admin only.

Ask a Super Admin to go to Admin → Members & Groups → Groups → the three dots beside the group → Manage members.

Three things worth knowing:

• Adding a lower-role member caps the group. A group's access level is limited by its least privileged member. If you add someone whose role can't hold the group's current level, you'll be warned first — and if you continue, the group grants less to everyone whose access came only from it. Anyone who also holds the access directly keeps it.
• Changing an existing member's role affects only them. When a member's role is lowered, their own access drops to the new ceiling. The group's level is unchanged, other members are unaffected, and the member stays in the group.
• Effective access is the higher of the two. If someone holds access both directly and through a group, the higher level applies. Adding an Owner to a Viewer group does not downgrade them.

11. Who is my Super Admin — and what if we don't have one, or they're unavailable?

You can see who holds Super Admin from Admin → Members & Groups, in the Role column of the Members list. Managers reach the same screen from the bottom of the left navigation bar.

Because Super Admins are the only users who can manage groups, assign the Super Admin role, and are auto-shared on every element, we recommend designating at least two so requests aren't blocked when one person is away.

If your organization has no Super Admin, or the only one has left, contact your Customer Success Manager — the first Super Admin has to be assigned on our side.

Notifications

12. Some of our users didn't receive the permissions emails

This is usually not a permissions problem. Some corporate email-security products open and click every link in an inbound message before delivering it — including unsubscribe links — which silently opts the recipient out of all Datarails email.

If users in your organization are missing notifications, contact Support and we can re-enable email for every user in your organization.

Related articles

• New Permissions: Roles & Permissions Overview — the five system roles, access levels, and element-level permissions in full.
• New Permissions: Data Access Management in Datarails — table access, permission filters, and drill-down control.
• New Permissions: User Management in Datarails — inviting users, editing roles, and managing groups.

Updated September 09, 2026 23:10