How to work out why a user can’t see something

A user reports that a menu, Report, or set of rows isn’t there. Access in Datanyx is granted at several independent layers, and a block at any one of them looks the same to the person affected. This article routes you from the symptom to the layer that’s actually responsible.

Before you begin

You need the Account Admin role and, from the user, a specific description of what’s missing. “Nothing works” isn’t diagnosable. “The Sales Summary Report isn’t in my Dashboard list” is.

Two things about the access model make this harder than it looks, and both are worth holding in mind before you start.

Access is additive, so removing it is hard. A user’s access is the union of every role they hold directly, every role from every group they belong to, and every role inherited from parent groups above those. Unchecking a permission in one role does nothing if a second role still grants it. When the complaint is “they can see something they shouldn’t,” you have to find every source, not just the obvious one.

Some restrictions are invisible to the user. Organization filter parameters silently drop rows and the user sees no filter chip and has no way to know a filter was applied. They’ll describe this as missing data, not as filtered data, and nothing in their view points at Organization Management.

Steps

Step 1. Match the symptom to a layer

Start here rather than working through every check. The symptom usually narrows it to one or two candidates.

What the user reports	Check first
The menu isn’t there at all	Organization, then menu access on every role they hold
The menu is there but they can’t create anything	Product subscription
A Report is missing from their Dashboard	Reports Access, then security tags
The Report opens but is empty or short on rows	Organization filter parameters, then row-level access
Some columns are missing	Restrict Field Access
It worked yesterday	A recent role edit, a group change, or a renamed column

Step 2. Build the real list of roles they hold

Before checking any permission, find every role the user actually has. There are three sources, and checking only the first is the most common reason a diagnosis goes wrong:

1. Roles assigned directly on their profile in User Management
2. Roles attached to every group they belong to, in Group Management
3. Roles inherited from the parent of each of those groups, and from every parent above that

Write them down. Every check below has to be run against all of them, not just the one you expect to be responsible.

Step 3. Confirm which organization they’re in

In User Management, check the user’s organization list and primary organization. If they’re signed in to the wrong organization, everything scoped to the right one is invisible and this looks identical to having no permissions at all.

This is the outermost gate. Nothing below it matters until it’s right.

Step 4. Confirm the subscription covers it

If the complaint is that a menu opens but nothing can be created inside it, the role is fine and the subscription isn’t. Designer access needs both the menu granted by a role and the product subscribed to by the workspace. Neither one substitutes for the other.

Step 5. Check menu access across every role

Open each role from your Step 2 list in Roles Management and check Menu Level Access. The user can open a menu if any single role grants it. If none do, that’s your answer.

Step 6. Check Report access and security tags

For a missing Report, there are two independent gates:

1. Reports Access on each role this lists specific Reports, and it doesn’t update itself. A Report built after the role was configured won’t be included until someone adds it.
2. Security tags if the Report carries a tag, the user needs a role paired with that tag. Check the Security action on each of their roles.

A newly built Report that nobody can see is nearly always the first of these.

Step 7. Check the data restrictions

If the Report opens but the data is wrong rather than absent, work down the Advanced tab of each role:

1. Restrict Dataset Access — the dataset itself may not be visible
2. Restrict Field Access — named fields are hidden at query time, so columns disappear while rows stay intact
3. Data Level Access — row filters scoped to the role

Both dataset and field restrictions match on exact names. If a column was renamed at the data source, the restriction stops matching and quietly stops applying. A restriction that used to work and now doesn’t is a strong signal that something upstream was renamed.

Step 8. Check the organization’s filter parameters

If rows are missing and nothing in Step 7 explains it, open the user’s organization in Organization Management and look at its configuration parameters.

Any parameter with Type set to Filter is applied to every Dashboard the user opens, invisibly. If the parameter’s Key matches a column in the Report, rows not matching its Value are dropped with no indication to the user. If the Key matches no column in that Report, the parameter is ignored for it which is why the same filter can affect one Report and not another.

Result

You’ve identified which layer is responsible and fixed it at that layer. Just as usefully, you know which layers weren’t responsible which is what stops the next report of the same symptom turning into another full audit.

If you’ve worked through every step and the access still isn’t behaving, the fault is likely below the Admin layer, in the Report or dataset itself. Hand it to the Designer who built it with your findings attached.

Common issues

1. I removed the role and they still have access. Another source grants it. Go back to Step 2 and check group and parent-group roles, not just direct assignments.
2. Two users with the same role see different things. They’re in different organizations, or one holds a second role the other doesn’t. Compare their full role lists and their organizations side by side.
3. The user sees the Report but no rows at all. Most likely an organization filter parameter whose Value doesn’t match anything in their data, or a row-level rule in one of their roles. Check the parameter first, it’s invisible to the user and easy to overlook.
4. Access appeared without anyone granting it. Someone was added to a group, or a role attached to a group they’re already in was edited. Group changes affect every member at once, including members of every subgroup below.
5. A restriction that worked for months suddenly stopped. A column was renamed at the data source. Dataset and field restrictions match by exact name and fail silently when the name changes.