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.