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.