An agent is following a written instruction that says to open a particular settings screen. They cannot find it. The person who wrote the instruction is looking at their own screen, where the entry is plainly there, in the section the instruction names.
Nothing is broken and nobody is looking in the wrong place. The dashboard sidebar is built per person, and entries an account is not allowed to open are removed before the page is drawn. Two people signed in to the same account can legitimately see two different menus.
Once you know that, the whole class of confusion resolves quickly, and a few related behaviours stop looking like glitches.
The menu is not the lock
This is the part worth internalising before anything else. Hiding a menu entry is a courtesy, not a control. The real enforcement happens when a page is requested: every dashboard screen is checked against what the signed-in account is allowed to open, and a request that fails the check never runs the page.
The check runs early, before the screen's own logic and before any form submission is handled, so a denied request cannot half-execute. Typing the address by hand, keeping an old bookmark, or following a link from a document all land in the same place.
The menu filter exists so that a person is not shown a list of entries that will bounce them. If it were removed tomorrow, the extra entries would reappear and every one of them would still refuse to open. That is a cosmetic regression, not a security hole, and it is a useful way to think about what the sidebar is actually for.
What actually gets removed
The account-level distinction is administrator versus everyone else. An administrator sees the menu exactly as it is defined. For everyone else, entries pointing at administrator-only screens are dropped.
The screens on that list are the ones where a change is not reversible by the person affected: the screens that manage who is on the team and who holds the administrator flag, the sign-on configuration, API credentials, and privacy operations such as erasing a person's data. The common thread is that opening them is equivalent to granting yourself more access, so they are restricted regardless of how the menu looks.
Filtering also only applies to the dashboard. Other consoles that share the same menu machinery load their own definitions and are never touched by a dashboard rule, which is why a restriction you set for the dashboard has no bearing on what a different console shows.
Empty sections and orphaned labels go too
Removal is not just row by row. If a whole section is addressed by an administrator-only screen, the section goes as a unit. If a section survives but every row inside it was removed, the now-empty section is dropped rather than left as a heading that opens onto nothing.
The same tidying applies to the non-clickable labels that break up long sections. A label is a heading for the rows beneath it, so once those rows are gone the label is removed as well. This is why an agent's sidebar is not simply the administrator's with gaps in it: it is genuinely shorter, and the shape differs enough that step-by-step instructions written from an administrator's screen can be hard to follow.
The practical consequence for documentation is small but real. Write internal instructions from the screen of the person who will follow them, or name the destination rather than the path taken to reach it.
The check fails closed
If the administrator test cannot be completed for any reason, the code treats the account as not an administrator. Hiding too much is recoverable in seconds; revealing a restricted entry because a check failed is not.
The visible symptom of this is a menu that briefly looks like an agent's to somebody who is definitely an administrator. If that ever happens, the useful response is to reload rather than to start changing permissions, because the menu is a rendering of the check and not the state of the check itself.
Where the denied banner comes from
When a request is refused, it is not dropped or shown as an error page. It is redirected to the dashboard overview with a marker naming the screen that was refused, which is what produces the message telling you that a particular screen is not available to your account.
That design is deliberate and worth knowing when you read a support report. Somebody saying they clicked a link and ended up on the overview page is describing a permission refusal, not a broken link. The name in that message tells you exactly which screen to grant, or which instruction to rewrite.
The menu definition is read from a file and kept in memory for the whole application rather than re-read on every request. It is refreshed when that file's modification time changes, so an edit is picked up without a restart, but a change to who is an administrator is a different thing entirely.
Account changes take effect for the affected person on their next request, because the filtering is done per request against their own account. What is shared is only the underlying definition of the menu, never one person's filtered copy of it. That distinction matters: it is what stops one person's restrictions from leaking into everybody else's sidebar.
How the highlighted row is chosen
The sidebar highlights the row you are on by comparing file names, not full paths. The query string and any anchor are stripped first, so a screen opened with parameters still highlights correctly.
Menu rows can also claim additional screens as their own, which is how a detail view highlights the list it belongs to. Opening a single ticket keeps the support entry highlighted rather than clearing the sidebar, because the detail screen is registered against that row.
The behaviour to be aware of is that matching on file name alone means two screens with the same file name in different folders look identical to the highlighter. It is a display detail rather than a functional one, but it explains the occasional row that lights up where you did not expect it.
How MyLiveChat fits
Today the meaningful distinction across the dashboard and its admin controls is administrator or agent. There is no per-screen permission editor, so the answer to a request for one person to reach one restricted screen is either to make them an administrator or to have an administrator do that task. Choosing deliberately between those two is the substance of access control for support teams, and it is worth deciding once rather than case by case.
Finer-grained scopes do exist, but on API credentials rather than on dashboard sign-ins, which is the right tool when the requirement is really an integration rather than a person.
When somebody reports that a screen has vanished, work through it in this order: confirm whether they are an administrator, ask whether they landed on the overview with a message naming the screen, and only then look for a fault. Nearly every report of this kind ends at the first question. If you are also standardising what new starters can reach, onboarding new support agents covers the account setup, and what your dashboard search looks through covers the other screen people assume is broken when it is simply narrower than they expect.
The menu can also differ in a second, simpler way: the language it is drawn in is a per-browser choice rather than an account setting, which which parts of your dashboard change language explains.
A menu that draws normally while a settings screen underneath it will not load is a different problem again: when your dashboard cannot reach your chat server covers the hop those screens depend on.