Admin Panel

The Two Panels

There are two administration interfaces, and confusing them is the single most common source of "I cannot find that screen".

Where to find it

Architect Panel → Layout & Pages:

• Admin Panel Builder — categories, then View Items on a row

Architect Panel → Configuration:

• Site Settings — installation configuration, in the Architect Panel

The Architect Panel

Where the application is built. Datastores, fields, views, layouts, workflows, security groups, integrations, settings — everything that defines how the system behaves.

It is organised into categories by subject and is intended for a small number of people.

The Admin Panel

Where the application is administered. Day-to-day tasks by people who run the business rather than build the system — managing users, working queues, running the operational screens.

It is built from your own categories and items, so it shows what your organisation actually needs.

The distinction is build against run

"Add a field to the case record" is architecture. "Add a user to the support team" is administration. Different people, different frequency, different consequences of a mistake.

Why it matters

Because the panels have different audiences, and giving somebody the Architect Panel because they needed one administrative task is how an operational user acquires the ability to change your schema.

Much is behind row actions

In both panels. A great deal of functionality — permissions, security groups, related lists, builders — is reached by an action on a row rather than by a menu entry.

If a capability appears to be missing, look at the rows before concluding it does not exist.

Build the Admin Panel deliberately

An empty Admin Panel pushes everybody into the Architect Panel, which is the outcome the split exists to prevent. If your administrators are working in the Architect Panel daily, the Admin Panel needs building.

Grant accordingly

Architect access to the few people who design the system. Admin Panel access to the people who run it. Reviewing who holds the first is worth doing occasionally.

Worked example

An organisation found five operational staff with architect access, granted during setup for tasks that were actually administration. Building three Admin Panel categories covering those tasks let the access be removed without anybody losing what they needed.

Recommendations

• Architect for building, Admin for running.
• Build the Admin Panel or everybody ends up in the wrong one.
• Look for row actions before assuming something is missing.
• Review who has architect access.

Using the Admin Panel

The Admin Panel is built from categories, each holding items that open a screen.

Where to find it

Architect Panel → Layout & Pages:

• Admin Panel Builder — categories, then View Items on a row

Categories and items

A category has a name, a description and an order. An item within it has a friendly name, a description, an icon, the action it performs, its order, and optionally a count and criteria deciding when it appears.

The counts are the useful part

An item can display a number — how many records are waiting, how many are overdue, how many need approval. That turns the panel from a menu into a dashboard somebody can read in a second.

An item without a count is a link. An item with one tells you whether you need to click it.

Choose counts that prompt action

"Requests awaiting approval" is worth showing. "Total records" is not — it goes up forever and nobody acts on it.

The test: would a person do something differently because that number changed?

Items can be conditional

Criteria decide whether an item appears at all. That is how the panel stays relevant for different people rather than showing everybody everything.

Order by frequency

What people do daily at the top, weekly next, occasional last. The panel should reward the common case rather than presenting an alphabetical inventory.

Write real descriptions

The description is what tells somebody whether this is the screen they want. "Users" is a label; "Add, disable and reset staff accounts" is an answer.

Icons help more than they look

People navigate a familiar panel by shape and position rather than by reading. Consistent, distinguishable icons make a frequently used panel much faster.

Keep it short

A panel with sixty items is a panel people search rather than read. Four or five categories with a handful of items each is a panel somebody learns.

Permissions apply per item

Items carry their own permissions, reached from the row. So the panel can be one definition showing different things to different people, rather than several panels.

Worked example

An organisation runs four categories — Users, Queues, Reporting and Data — with counts on the three items that represent work waiting. Staff check the panel each morning and act on the numbers, which replaced a daily e-mail nobody read.

Recommendations

• Counts on anything representing work waiting.
• Order by how often people use it.
• Descriptions that answer a question, not labels.
• Four or five categories, not sixty items.

Building the Panel

The Admin Panel is yours to define, and building it well is a couple of hours that pays back daily.

Where to find it

Architect Panel → Layout & Pages:

• Admin Panel Builder — categories, then View Items on a row

Admin Panel → User Administration:

• User Groups — who sees each item

Start from what people do

Not from what screens exist. List the ten things your administrators do most often, in the order of how often, and build the panel around those.

A panel built by cataloguing available screens is a directory; one built from tasks is a tool.

Create categories first

Each with a name, a description and an order. Group by what somebody is trying to achieve — Users, Work, Reporting — rather than by which part of the system a screen belongs to.

Then add items

Each item names the screen it opens, its friendly name, description and icon, and its order within the category. Items are reached from the category through View Items on its row.

Add counts where they mean something

An item can run a query producing a number. Use it for anything representing outstanding work, and keep those queries cheap — the panel runs them every time somebody opens it.

A slow count is a slow panel, and the panel is the first thing people see.

Use criteria to hide the irrelevant

An item can appear conditionally. That is how a panel serves several roles without becoming the union of everything any of them needs.

Set permissions per item

Reached from the item’s row. Permissions are what make one panel definition work for everybody — each person sees the items they may use and nothing else.

Test that by signing in as somebody else, not by reading the configuration.

Build it iteratively

Publish something useful quickly, then adjust. A panel designed exhaustively before anybody uses it is a panel designed around assumptions.

Ask what people still do elsewhere

The best signal. If your administrators are still going into the Architect Panel for something, that something belongs on the Admin Panel.

Review it as the organisation changes

Items for processes that no longer exist, counts that are always zero, categories nobody opens. A panel that reflects last year’s work is one people stop trusting.

Worked example

A team built four categories from a list of its ten most frequent tasks, added counts to three items, and set permissions so operational staff see two categories and managers see all four. Asking what people still did in the Architect Panel added two items in the first month.

Recommendations

• Build from tasks, not from available screens.
• Keep count queries cheap.
• Set item permissions and test by signing in as somebody else.
• Ask what people still do elsewhere.

Dark Mode and Compact Layout

The administration screens have two display controls of their own: a light or dark theme, and a compact or comfortable layout. Each person can choose for themselves on each device, so somebody working long hours in a data grid can have it the way they find easiest to read.

Where to find it

There is no panel tile. Both controls are small icons on the top row of the left-hand menu in the administration screens, beside the button that collapses the menu:

• Theme: a moon or a sun. Its tooltip reads "Switch to dark mode" or "Switch to light mode".
• Layout: two arrows pointing out or in. Its tooltip reads "Switch to comfortable layout" or "Switch to compact layout".

Each icon shows the mode you would get by clicking it, not the one you are in.

What the two layouts are

• Compact (the default): everything in the administration screens is drawn about an eighth smaller, which is roughly what many people were doing by zooming their browser out to 85% or so. Grids show more rows and forms need less scrolling.
• Comfortable: the full, browser-default size.

Compact is a proportion, not a fixed size, so somebody who has raised their browser's default text size for accessibility keeps that increase. On a touch device (a phone or tablet) compact is ignored and the full size is used, because shrinking buttons below a comfortable finger size makes them harder to hit.

Changing them

1. Open the Architect Panel or the Admin Panel. If the menu is collapsed to icons, expand it first: the layout icon is hidden while the menu is collapsed, because there is no room for it.
2. Click the moon or sun to switch theme. The change is immediate; nothing reloads.
3. Click the arrows to switch between compact and comfortable. Again the change is immediate.

How your choice is remembered

Both choices are stored in your browser on that device, not against your user account. That is deliberate: the choice has to be known before the page is drawn, so the screen never flashes the wrong theme first. It also means:

• Another computer starts from the defaults. Set it again there.
• A private window, or a browser that blocks site data, forgets the choice when it closes. The switch still works for that session.
• Nobody else is affected. Your choice changes only what you see.

The defaults

Before anyone chooses, each installation has a default theme and a default layout, set by the hosting administrator in the site configuration file. Layout defaults to compact. If you have never chosen a theme and your computer's own setting asks for dark mode, the administration screens open dark; your own choice on the icon always wins.

What goes wrong and how to tell

• The layout icon has disappeared: the menu is collapsed. Expand it.
• The setting does not stick between visits: the browser is not keeping site data (private browsing or a privacy setting).
• Compact has no effect on a tablet: by design, touch devices always get the full size.
• Part of a screen stays light in dark mode: a few older screens set their own light background. Those areas are deliberately kept light, with dark text, so they stay readable rather than turning into pale text on a dark page.

Worked example

An operations administrator spends their day in the Admin Panel's work queues on a 13-inch laptop. With the compact layout they see most of a queue without scrolling, and in the evening they switch to dark mode with the moon icon. On the large monitor in the office they prefer comfortable, so they click the layout icon there once; each machine remembers its own setting, and their colleagues' screens are unchanged.

Recommendations

• Tell new administrators the icons exist; many people zoom their browser instead.
• Use comfortable on shared or presentation screens, where people read from further away.
• Do not rely on it following a person between devices; it is per browser.
• Report a screen that is hard to read in dark mode rather than living with it.

Quick Filter Rows on Admin Lists

A list opened from an Admin Panel item can show a row of one-click filter boxes above the grid: one box per value of a chosen field, such as each status or each site. Staff narrow the list with a single click instead of opening a column filter, which suits queues that are worked by status every day.

Where to find it

There is no separate screen. The filter row is switched on in the action of the Admin Panel item that opens the list:

Architect Panel → Layout & Pages:

• Admin Panel Builder — categories, then View Items on a row, then the item's action

Which fields can be used

• Dropdown fields linked to another datastore (single or searchable): one box per linked record.
• Pills: one box per pill title.
• Conditional (miniform) fields: one box per option.
• Date and date and time fields: a From and To pair with Apply and Clear, rather than boxes.

Any other type, including a toggle switch, a tickbox or a plain text field, draws nothing at all: the list looks normal and the only trace is a line in the error log saying the type "is not currently supported as a filter field". If a yes/no field needs a filter row, convert it to pills first; a pills field stores its choice as 0, 1 and so on, so a toggle's existing values carry over.

Switching it on

1. Note the row name of each field to filter on, from the datastore's Fields list.
2. In the Admin Panel Builder, open the category, then View Items, and edit the item that opens the list.
3. At the end of the page address inside its action, add &filters= followed by the row names, comma-separated, for example &filters=status,site.
4. Optionally add &filtertype=dropdown to show each filter as a drop-down list instead of boxes. Boxes (pill) are the default.
5. Save, reopen the Admin Panel item and check the row appears.

The same works on lists opened from a user input view's stage list, and the filter keeps the stage you were looking at.

How it behaves

• Each field draws its own row: its label, a View All box, and one box per value. The selected box is highlighted green.
• Clicking a box reloads the list showing only that value. Choices on different fields combine.
• One value per field at a time; View All clears that field's choice.

This is a different feature from the funnel on each column heading, which offers operators such as "contains" on any column. The filter row offers one click on a few chosen fields.

What goes wrong and how to tell

• No row appears: the field type is not supported, or the row name is misspelt. Check the error log for "is not currently supported as a filter field" or "cannot be found".
• The row worked, then disappeared: somebody edited the item's action and dropped the parameters.

Worked example

A placements team works an Applications list by induction status. Induction Status was a toggle, so the architect converts it to pills titled "Not confirmed" and "Confirmed", which keeps every existing value. They add &filters=inductionstatus to the end of the Admin Panel item's action. Co-ordinators now see "View All", "Not confirmed" and "Confirmed" above the list and clear the outstanding inductions with one click each morning.

Recommendations

• Use it for the field people sort their work by: status, site, owner.
• Keep to one or two fields; each adds a row of boxes.
• Use drop-downs for fields with many values.
• Check the error log if a row you added does not appear.